Upstream has announced version 2.10.8 today (January 28): https://developer.pidgin.im/wiki/ChangeLog It fixes a multitude of security issues and other bugs, including these CVEs: (CVE-2012-6152) (CVE-2013-6477) (CVE-2013-6478) (CVE-2013-6479) (CVE-2013-6481) (CVE-2013-6482) (CVE-2013-6483) (CVE-2013-6484) (CVE-2013-6485) (CVE-2013-6486) (CVE-2013-6487) (CVE-2013-6489) (CVE-2013-6490) (CVE-2014-0020) It is already in Mageia 3 and Cauldron SVN, and I've tested and confirmed that it builds and works fine in Cauldron, including connecting to AIM and Google Talk accounts. I've asked for a freeze push for Cauldron/Mageia 4, but we'll see if it's too late or not. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Updated packages uploaded for Mageia 3 and Cauldron. Advisory: ======================== Updated pidgin packages fix security vulnerabilities: Many places in the Yahoo! protocol plugin assumed incoming strings were UTF-8 and failed to transcode from non-UTF-8 encodings. This can lead to a crash when receiving strings that aren't UTF-8 (CVE-2012-6152). A remote XMPP user can trigger a crash on some systems by sending a message with a timestamp in the distant future (CVE-2013-6477). libX11 forcefully exits causing a crash when Pidgin tries to create an exceptionally wide tooltip window when hovering the pointer over a long URL (CVE-2013-6478). A malicious server or man-in-the-middle could send a malformed HTTP response that could lead to a crash (CVE-2013-6479). The Yahoo! protocol plugin failed to validate a length field before trying to read from a buffer, which could result in reading past the end of the buffer which could cause a crash when reading a P2P message (CVE-2013-6481). NULL pointer dereferences in the MSN protocol plugin due to a malformed Content-Length header, or a malicious server or man-in-the-middle sending a specially crafted OIM data XML response or SOAP response (CVE-2013-6482). The XMPP protocol plugin failed to ensure that iq replies came from the person they were sent to. A remote user could send a spoofed iq reply and attempt to guess the iq id. This could allow an attacker to inject fake data or trigger a null pointer dereference (CVE-2013-6483). Incorrect error handling when reading the response from a STUN server could lead to a crash (CVE-2013-6484). A malicious server or man-in-the-middle could cause a buffer overflow by sending a malformed HTTP response with chunked Transfer-Encoding with invalid chunk sizes (CVE-2013-6485). A malicious server or man-in-the-middle could send a large value for Content-Length and cause an integer overflow which could lead to a buffer overflow in Gadu-Gadu HTTP parsing (CVE-2013-6487). A specially crafted emoticon value could cause an integer overflow which could lead to a buffer overflow in MXit emoticon parsing (CVE-2013-6489). A Content-Length of -1 could lead to a buffer overflow in SIMPLE header parsing (CVE-2013-6490). A malicious server or man-in-the-middle could trigger a crash in IRC argument parsing in libpurple by sending a message with fewer than expected arguments (CVE-2014-0020). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6152 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6477 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6478 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6479 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6481 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6482 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6484 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6485 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6487 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6489 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6490 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0020 http://pidgin.im/news/security/?id=70 http://pidgin.im/news/security/?id=71 http://pidgin.im/news/security/?id=72 http://pidgin.im/news/security/?id=73 http://pidgin.im/news/security/?id=74 http://pidgin.im/news/security/?id=75 http://pidgin.im/news/security/?id=76 http://pidgin.im/news/security/?id=77 http://pidgin.im/news/security/?id=78 http://pidgin.im/news/security/?id=79 http://pidgin.im/news/security/?id=80 http://pidgin.im/news/security/?id=82 http://pidgin.im/news/security/?id=83 http://pidgin.im/news/security/?id=84 http://pidgin.im/news/security/?id=85 https://developer.pidgin.im/wiki/ChangeLog ======================== Updated packages in core/updates_testing: ======================== pidgin-2.10.8-1.mga3 pidgin-plugins-2.10.8-1.mga3 pidgin-perl-2.10.8-1.mga3 pidgin-tcl-2.10.8-1.mga3 pidgin-silc-2.10.8-1.mga3 libpurple-devel-2.10.8-1.mga3 libpurple0-2.10.8-1.mga3 libfinch0-2.10.8-1.mga3 finch-2.10.8-1.mga3 pidgin-bonjour-2.10.8-1.mga3 pidgin-meanwhile-2.10.8-1.mga3 pidgin-client-2.10.8-1.mga3 pidgin-i18n-2.10.8-1.mga3 from pidgin-2.10.8-1.mga3.src.rpm
Version: Cauldron => 3Assignee: bugsquad => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => (none)Severity: normal => critical
CC: (none) => davidwhodginsWhiteboard: (none) => advisory
Testing complete on Mageia 3 i586 and x86_64. Someone from the sysadmin team please push 12468.adv to updates.
Keywords: (none) => validated_updateWhiteboard: advisory => advisory MGA3-64-OK MGA3-32-OKCC: (none) => sysadmin-bugs
No, please don't. facebook.com and jabber.org don't work anymore with pidgin 2.10.8. However, upstream has a fix: https://developer.pidgin.im/ticket/15879#comment:30
CC: (none) => goetz.waschk
Removing validated status per comment #3
Keywords: validated_update => (none)CC: (none) => stormiWhiteboard: advisory MGA3-64-OK MGA3-32-OK => advisory
I'd rather get this out there (as you can still keep the old version if you need those two protocols) as we can still update it again later (which we'll have to anyway, at least for mga4). If the mga3 update gets held, I won't be able to fix it until after Cauldron re-opens after the mga4 release as I'll need to fix it for Cauldron and mga4 at the same time. I'd much rather get this out there now and we could just add a note to the advisory about those two protocols and say another update in the near future will fix them.
I really don't feel it's right to push an update with known regressions, when we have a patch available. My proposal is: nuke pidgin-2.10.8-1.mga3, apply the patch, submit it again with now release change so that upgrade still goes smoothly. Then when mga4 updates are opened, push a pidgin-2.10.8-1.mga3 with the same patch. People who migrate to mga4 will get the regression, but the many who don't in the timeframe before the mga4 update is pushed will be fine with both the security update and no regression. Not totally convenient, but pushing an update with regressions is worse to me. Now, if other QA team members disagree with me (or sysadmins veto for a reason I would not have foreseen), just tell and validate the update again.
Unless we can fix it in Mageia 4 (and it's too late for that), we're not just gonna respin the mga3 update and leave the mga4 version broken. If QA objects to releasing this, then it'll just have to wait. I wish upstream would have done better QA and prevented this in the first place. 2.10.8 has only been in development for 11 months, you'd think they could have caught this before releasing :o(
(In reply to David Walser from comment #7) > Unless we can fix it in Mageia 4 (and it's too late for that), we're not > just gonna respin the mga3 update and leave the mga4 version broken. So you're saying that it would be bad, nearly impossible to envision ("we're not gonna"), to wait for mga4 to break it and rather break it right now in mga3. I propose: Mga3 release: security issues Mga3 updates: fixed security issues, no regression Mga4 release: fixed security issues, regression You prefer: Mga3 release: security issues Mga3 updates: fixed security issues, regression Mga4 release: fixed security issues, regression still there I don't want a Mga3 release to Mga3 updates with regressions, you don't want a Mga3 updates to Mga4 release with regressions. There will be a regression, it's a matter of choosing when it occurs and for how much time. Avoiding to break mga3 leaves us with a regression in mga4 only, which can be written in the Errata and fixed very quickly as soons as updates media are available.
Cauldron and mga4 updates are reopened. Let's fix them both.
Version: 3 => 4Whiteboard: advisory => mga3too advisory feedback
(In reply to Samuel VERSCHELDE from comment #9) > Cauldron and mga4 updates are reopened. Let's fix them both. I mean, let's fix them all, including mga3.
Whiteboard: mga3too advisory feedback => MGA3TOO advisory feedback
Whiteboard: MGA3TOO advisory feedback => MGA3TOO feedback
The advisory in Comment 1 still stands for Mageia 3. Damien has updated it to 2.10.9, so here's the updated package list: pidgin-2.10.9-1.mga3 pidgin-plugins-2.10.9-1.mga3 pidgin-perl-2.10.9-1.mga3 pidgin-tcl-2.10.9-1.mga3 pidgin-silc-2.10.9-1.mga3 libpurple-devel-2.10.9-1.mga3 libpurple0-2.10.9-1.mga3 libfinch0-2.10.9-1.mga3 finch-2.10.9-1.mga3 pidgin-bonjour-2.10.9-1.mga3 pidgin-meanwhile-2.10.9-1.mga3 pidgin-client-2.10.9-1.mga3 pidgin-i18n-2.10.9-1.mga3 from pidgin-2.10.9-1.mga3.src.rpm For Mageia 4, it'll be a different advisory, and just a MGAA, as it's a non-security fix there. The advisory text is: Pidgin has been updated to version 2.10.9 to fix problems logging into some servers, including jabber.org and chat.facebook.com. References: https://developer.pidgin.im/ticket/15879 https://developer.pidgin.im/wiki/ChangeLog The package list is below: pidgin-2.10.9-1.mga4 pidgin-plugins-2.10.9-1.mga4 pidgin-perl-2.10.9-1.mga4 pidgin-tcl-2.10.9-1.mga4 pidgin-silc-2.10.9-1.mga4 libpurple-devel-2.10.9-1.mga4 libpurple0-2.10.9-1.mga4 libfinch0-2.10.9-1.mga4 finch-2.10.9-1.mga4 pidgin-bonjour-2.10.9-1.mga4 pidgin-meanwhile-2.10.9-1.mga4 pidgin-client-2.10.9-1.mga4 pidgin-i18n-2.10.9-1.mga4 from pidgin-2.10.9-1.mga4.src.rpm
CC: (none) => mageiaWhiteboard: MGA3TOO feedback => MGA3TOO
Blocks: (none) => 12486
Thanks Damien. QA team, if you'd like to use Bug 12486 for the Mageia 4 update and this bug for the Mageia 3 update, if that'd make things easier, we can do that.
Yes, separating bugs will ease the handling of 2 different advisories, one security and one bugfix. Adding bug 12486 as a blocking this one so that we don't issue an higher version of pidgin in mageia 3 than mageia 4. But we must test both fast. QA team, to your computers!
Blocks: 12486 => (none)Depends on: (none) => 12486
Version: 4 => 3Whiteboard: MGA3TOO => (none)
URL: (none) => http://lwn.net/Vulnerabilities/584148/
Advisory updated for new srpm
Whiteboard: (none) => advisory
Testing complete mga3 64. I'll test mga3 32 shortly.
Whiteboard: advisory => advisory mga3-64-ok
Testing complete mga3 32 Validating Could sysadmin please push from 3 core/updates_testing to updates. There is an separate bug with similar number for mga4 which will need to be pushed first or together bug 12486 Thanks
Keywords: (none) => validated_updateWhiteboard: advisory mga3-64-ok => advisory mga3-64-ok mga3-32-ok
Update pushed: http://advisories.mageia.org/MGASA-2014-0034.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED