These applications include a slightly modified zlib and also libpng, both outdated and vulnerable (see relevant GLSAs). optipng-0.5 and pngcrush-1.6.2 need to go stable.
optipng is safe, had already been fixed (somebody bumped it without my permission, but it still is safe).
Hm. pngcrush is no-herd. Carsten, Tavis, graphics herd, any takers ?
Bumped to 1.6.2 in cvs.
(In reply to comment #2) > Hm. pngcrush is no-herd. Carsten, Tavis, graphics herd, any takers ? Committed before I filed the bug.
Arches please test and mark pngcrush-1.6.2 stable
ppc stable
x86 stable
From upstream homepage: Pngcrush, when statically linked to the supplied zlib code, is believed to be immune to the zlib-1.1.3 "double-free" bug, since by default it detects and rejects any "double-free" attempt. It merely generates a "Decompression Error" message and rejects the file. So, do we believe that, too (-> only libpng issues left)?
Yes, but there's also been the zlib heap overflow since then, and pngcrush is definitely vulnerale to that: $ pngcrush -q zlib-testcase.png foo.png While converting zlib-testcase.png to foo.png: pngcrush caught libpng error: incomplete literal/length tree Segmentation fault (core dumped) I have a testcase png image here http://dev.gentoo.org/~taviso/files/zlib/zlib-testcase.png
i can confirm the segfault in comment #9, think this should go back to ebuild status. or is it a different issue and should i mark it stable on amd64 nevertheless?
I can confirm the segfault, too. I had a look at the zlib code included with pngcrush-1.6.2 and indeed it is version 1.2.3. So, I don't know what to do/where to look.
blubb, vanquirius: does the segfault happen with the latest patches and security fixes applied (afaik, that should be version 1.6.2)?
Yup. Which is not a good thing.
Ok, taviso had a look at it and stated that this is nothing with a security impact. Do you (arches) think this is minor enough to ignore, so you can stable nevertheless? If not, I'll put it back to ebuild status.
yeah, i think so. would be nice to get it fixed nevertheless though marked stable
Carsten thanks for reporting (again). GLSA 200603-18