[arch-dev-public] APNG patch in libpng
Hey guys, Recent exploit found in libpng < 1.2.27 (http://bugs.archlinux.org/task/10192#comment27550) is getting a lot of attention in our forums and bugtrackers, however since the APNG patch (included for firefox3's sake - http://bugs.archlinux.org/task/9570) isn't updated for the new libpng version yet, I'm blocked on updating this. If I drop APNG from libpng to ensure we get updates as quick as possible, this means firefox3 will need to be rebuilt without system PNG. If this happens, that means firefox3 will be using a vulnerable version of the library, but I can react quicker to vulnerabilities like this in the future. I'm not sure what is the best course of action. Wait until a new APNG patch is released? Update and force firefox3 to rebuild?
From the libpng website: "The pngtest sample application distributed with libpng, pngcrush, and certain versions of ImageMagick are known to be affected, but the bug is otherwise believed to be quite rare." - if the bug is quite rare, can we put it off?
Any input?
On Wed, 2008-04-30 at 15:44 -0400, Travis Willard wrote:
Hey guys,
Recent exploit found in libpng < 1.2.27 (http://bugs.archlinux.org/task/10192#comment27550) is getting a lot of attention in our forums and bugtrackers, however since the APNG patch (included for firefox3's sake - http://bugs.archlinux.org/task/9570) isn't updated for the new libpng version yet, I'm blocked on updating this.
If I drop APNG from libpng to ensure we get updates as quick as possible, this means firefox3 will need to be rebuilt without system PNG. If this happens, that means firefox3 will be using a vulnerable version of the library, but I can react quicker to vulnerabilities like this in the future.
I'm not sure what is the best course of action. Wait until a new APNG patch is released? Update and force firefox3 to rebuild?
From the libpng website: "The pngtest sample application distributed with libpng, pngcrush, and certain versions of ImageMagick are known to be affected, but the bug is otherwise believed to be quite rare." - if the bug is quite rare, can we put it off?
Any input?
I tried to build libpng 1.2.27 with apng patch, this is what I did to get a working package: - apply the 1.2.25-apng patch, ignore the reject: the rejected patch adds checks that don't make sense with 1.2.27 as the variables should be NULL anyways. - Generate a new patch out of this, so we have a clean patch against 1.2.27 - Run the whole libtoolize --force --copy, aclocal, autoconf, automake crap - Run every make command with "ECHO=echo" appended, as libtool 2.2 doesn't export this variable anymore (it's lt_ECHO now) This resulted in a 1.2.27 package that still works with animated PNGs in firefox 3.0b5. OK to commit to testing?
On Thu, May 1, 2008 at 6:04 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-04-30 at 15:44 -0400, Travis Willard wrote:
Hey guys,
Recent exploit found in libpng < 1.2.27 (http://bugs.archlinux.org/task/10192#comment27550) is getting a lot of attention in our forums and bugtrackers, however since the APNG patch (included for firefox3's sake - http://bugs.archlinux.org/task/9570) isn't updated for the new libpng version yet, I'm blocked on updating this.
If I drop APNG from libpng to ensure we get updates as quick as possible, this means firefox3 will need to be rebuilt without system PNG. If this happens, that means firefox3 will be using a vulnerable version of the library, but I can react quicker to vulnerabilities like this in the future.
I'm not sure what is the best course of action. Wait until a new APNG patch is released? Update and force firefox3 to rebuild?
From the libpng website: "The pngtest sample application distributed with libpng, pngcrush, and certain versions of ImageMagick are known to be affected, but the bug is otherwise believed to be quite rare." - if the bug is quite rare, can we put it off?
Any input?
I tried to build libpng 1.2.27 with apng patch, this is what I did to get a working package:
- apply the 1.2.25-apng patch, ignore the reject: the rejected patch adds checks that don't make sense with 1.2.27 as the variables should be NULL anyways. - Generate a new patch out of this, so we have a clean patch against 1.2.27 - Run the whole libtoolize --force --copy, aclocal, autoconf, automake crap - Run every make command with "ECHO=echo" appended, as libtool 2.2 doesn't export this variable anymore (it's lt_ECHO now)
This resulted in a 1.2.27 package that still works with animated PNGs in firefox 3.0b5.
OK to commit to testing?
Wow - you're awesome Jan. Go for it.
On Thu, 2008-05-01 at 07:20 -0400, Travis Willard wrote:
On Thu, May 1, 2008 at 6:04 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-04-30 at 15:44 -0400, Travis Willard wrote:
Hey guys,
Recent exploit found in libpng < 1.2.27 (http://bugs.archlinux.org/task/10192#comment27550) is getting a lot of attention in our forums and bugtrackers, however since the APNG patch (included for firefox3's sake - http://bugs.archlinux.org/task/9570) isn't updated for the new libpng version yet, I'm blocked on updating this.
If I drop APNG from libpng to ensure we get updates as quick as possible, this means firefox3 will need to be rebuilt without system PNG. If this happens, that means firefox3 will be using a vulnerable version of the library, but I can react quicker to vulnerabilities like this in the future.
I'm not sure what is the best course of action. Wait until a new APNG patch is released? Update and force firefox3 to rebuild?
From the libpng website: "The pngtest sample application distributed with libpng, pngcrush, and certain versions of ImageMagick are known to be affected, but the bug is otherwise believed to be quite rare." - if the bug is quite rare, can we put it off?
Any input?
I tried to build libpng 1.2.27 with apng patch, this is what I did to get a working package:
- apply the 1.2.25-apng patch, ignore the reject: the rejected patch adds checks that don't make sense with 1.2.27 as the variables should be NULL anyways. - Generate a new patch out of this, so we have a clean patch against 1.2.27 - Run the whole libtoolize --force --copy, aclocal, autoconf, automake crap - Run every make command with "ECHO=echo" appended, as libtool 2.2 doesn't export this variable anymore (it's lt_ECHO now)
This resulted in a 1.2.27 package that still works with animated PNGs in firefox 3.0b5.
OK to commit to testing?
Wow - you're awesome Jan. Go for it.
Checked into testing-64, including changelog about the changes. Please test and build for i686.
On Thu, May 1, 2008 at 7:33 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-01 at 07:20 -0400, Travis Willard wrote:
On Thu, May 1, 2008 at 6:04 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-04-30 at 15:44 -0400, Travis Willard wrote:
Hey guys,
Recent exploit found in libpng < 1.2.27 (http://bugs.archlinux.org/task/10192#comment27550) is getting a lot of attention in our forums and bugtrackers, however since the APNG patch (included for firefox3's sake - http://bugs.archlinux.org/task/9570) isn't updated for the new libpng version yet, I'm blocked on updating this.
If I drop APNG from libpng to ensure we get updates as quick as possible, this means firefox3 will need to be rebuilt without system PNG. If this happens, that means firefox3 will be using a vulnerable version of the library, but I can react quicker to vulnerabilities like this in the future.
I'm not sure what is the best course of action. Wait until a new APNG patch is released? Update and force firefox3 to rebuild?
From the libpng website: "The pngtest sample application distributed with libpng, pngcrush, and certain versions of ImageMagick are known to be affected, but the bug is otherwise believed to be quite rare." - if the bug is quite rare, can we put it off?
Any input?
I tried to build libpng 1.2.27 with apng patch, this is what I did to get a working package:
- apply the 1.2.25-apng patch, ignore the reject: the rejected patch adds checks that don't make sense with 1.2.27 as the variables should be NULL anyways. - Generate a new patch out of this, so we have a clean patch against 1.2.27 - Run the whole libtoolize --force --copy, aclocal, autoconf, automake crap - Run every make command with "ECHO=echo" appended, as libtool 2.2 doesn't export this variable anymore (it's lt_ECHO now)
This resulted in a 1.2.27 package that still works with animated PNGs in firefox 3.0b5.
OK to commit to testing?
Wow - you're awesome Jan. Go for it.
Checked into testing-64, including changelog about the changes. Please test and build for i686.
Re: your libtool fixes, did you build against the testing libtool? Is that even necessary?
On Thu, 2008-05-01 at 08:13 -0400, Travis Willard wrote:
Re: your libtool fixes, did you build against the testing libtool? Is that even necessary?
I used the testing libtool, but the one in core should work too. Without the modifications, both versions don't work anyways.
On Thu, May 1, 2008 at 9:02 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-01 at 08:13 -0400, Travis Willard wrote:
Re: your libtool fixes, did you build against the testing libtool? Is that even necessary?
I used the testing libtool, but the one in core should work too. Without the modifications, both versions don't work anyways.
Alright, it's been in testing long enough I think. I'll move them both to extra and bump to 1.2.28 at the same time (only changes between .27 and .28 were configure-script related, so the patch should still be clean.)
On Tue, May 6, 2008 at 8:13 AM, Travis Willard <travis@archlinux.org> wrote:
On Thu, May 1, 2008 at 9:02 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-01 at 08:13 -0400, Travis Willard wrote:
Re: your libtool fixes, did you build against the testing libtool? Is that even necessary?
I used the testing libtool, but the one in core should work too. Without the modifications, both versions don't work anyways.
Alright, it's been in testing long enough I think. I'll move them both to extra and bump to 1.2.28 at the same time (only changes between .27 and .28 were configure-script related, so the patch should still be clean.)
Just added to extra-i686, but something's buggerd in the sudoers file in my chroot in tygra so I can't build for x86_64 - if someone wants to build a new libpng on 64 from trunk (1.2.28) and remove the version in testing (1.2.27) that'd be super. Otherwise I've gotta wait for Aaron to get this sudoers thing resolved.
On Tue, May 6, 2008 at 8:24 AM, Travis Willard <travis@archlinux.org> wrote:
On Tue, May 6, 2008 at 8:13 AM, Travis Willard <travis@archlinux.org> wrote:
On Thu, May 1, 2008 at 9:02 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-01 at 08:13 -0400, Travis Willard wrote:
Re: your libtool fixes, did you build against the testing libtool? Is that even necessary?
I used the testing libtool, but the one in core should work too. Without the modifications, both versions don't work anyways.
Alright, it's been in testing long enough I think. I'll move them both to extra and bump to 1.2.28 at the same time (only changes between .27 and .28 were configure-script related, so the patch should still be clean.)
Just added to extra-i686, but something's buggerd in the sudoers file in my chroot in tygra so I can't build for x86_64 - if someone wants to build a new libpng on 64 from trunk (1.2.28) and remove the version in testing (1.2.27) that'd be super.
Otherwise I've gotta wait for Aaron to get this sudoers thing resolved.
n/m guys - I talked to Aaron and we got the issue sorted out. Building for x86_64 now
participants (2)
-
Jan de Groot
-
Travis Willard