should be fine, see the blocking bugs. =media-libs/libpng-1.2.43-r3 "amd64 x86" =media-libs/libpng-1.4.2 "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" amd64 needs also latest emul- packages, and they just got added, so i'd wait few weeks before cc'ing archteams here...
test & stabilize: =media-libs/libpng-1.2.44 (amd64 and x86 should be enough for this version) =media-libs/libpng-1.4.2 (everyone)
And the target keeps changing :-) Stabilize: =media-libs/libpng-1.2.44 (amd64 and x86 should be enough for this version) =media-libs/libpng-1.4.3 (everyone) <snip> Several versions of libpng through 1.4.2 (and through 1.2.43 in the older series) contain a bug whereby progressive applications such as web browsers (or the rpng2 demo app included in libpng) could receive an extra row of image data beyond the height reported in the header, potentially leading to an out-of-bounds write to memory (depending on how the application is written) and the possibility of execution of an attacker's code with the privileges of the libpng user (including remote compromise in the case of a libpng-based browser visiting a hostile web site). This vulnerability has been assigned ID CVE-2010-1205 (via Mozilla). An additional memory-leak bug, involving images with malformed sCAL chunks, is also present; it could lead to an application crash (denial of service) when viewing such images. Both bugs are fixed in versions 1.4.3 and 1.2.44, released 25 June 2010. </snip>
amd64 stable
Stable for HPPA.
It's probably just me, but the current 1.2.44 ebuild does not work for me on x86. It says "this ebuild is only for the libpng12.so.0 SONAME for ABI compat" and installs a libpng12.so.0 file only - no headers, no symlinks, nothing else. libpng-dependent applications won't compile with that. To reproduce: $ emerge --unmerge libpng $ emerge "=libpng-1.2.44" $ equery files libpng Is that an intended behaviour?
(In reply to comment #5) > Is that an intended behaviour? Yes, you get the headers/symlink/... from 1.4.3 (which is pulled in by the upgrade). 1.2.44 is only for binary apps, like vmware-server.
Archtested on x86: The rebuild went OK. I ran into a couple of already fixed issues and bug 320669, which is probably unrelated.
(In reply to comment #6) > Yes, you get the headers/symlink/... from 1.4.3 (which is pulled in by the > upgrade). 1.2.44 is only for binary apps, like vmware-server. To me this is a disappointing solution. I mean, if I $ emerge "=libpng-1.2.44" I expect to get the whole thing. Especially if it's a critical bugfix release. In my mind, if I for some reason do not want to upgrade to 1.4 now then Gentoo shouldn't get in my way. As a personal solution I've cooked my own 1.2.44 ebuild from the 1.2.43-r2 ebuild, and it works fine. But this is a bit odd. Florian
There is no reason to not upgrade to 1.4.3.
Well. In my case I just wanted a quick bugfix and postpone a possible thorough revdep-rebuild until later. In the long run you are of course right.
x86 stable, thanks Thomas, my rebuilts also went fine
In my case revdep-rebuild showed only some non-critical packages depending on libpng12 (like obex). I still can't compile new packages. Using trial-and-error I figured to remerge cairo and pango but still lots of packages can't be merged. Then I made my own libpng:1.2 ebuild which has libpng12.so and libpng12.la and all problems went away. I want to stress this once again: revdep-rebuild showed none critical packages.
I've had similar problems and reverted. I didn't have enough time to look at it, though.
ppc64 stable
Stable on alpha.
arm/ia64/m68k/s390/sh/sparc stable
Marked ppc stable.
CVE-2010-1205 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-1205): Buffer overflow in pngpread.c in libpng before 1.2.44 and 1.4.x before 1.4.3, as used in progressive applications, might allow remote attackers to execute arbitrary code via a PNG image that triggers an additional data row.
Samuli: only change the whiteboard to glsa, after it was filed in our glsamaker tool. As only the security team adds glsas there, it's safe to say that you should never change the whiteboard to [glsa].
GLSA 201010-01
