libpng: update to 1.2.43

libpng: update to 1.2.43

I unpacked libpng 1.2.43 and did:
  cd third_party/libpng
  for x in $(ls -1) ; do cp /tmp/libpng-1.2.43/$x .; done

The diffs appear to all be safe. The Chromium specific config is in pngusr.h
and isn't touched by this change.

1.2.43 fixes http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0205

c7013d773eb45b8ed6a864e419e544106a0dd95d  /tmp/libpng-1.2.43.tar.xz

BUG=38512
TEST=none

[agl, 2010-03-18 15:47:53]

(I don't know if you're the right person for this - feel free to decline. But
from the logs, nobody seems to be the go-to person for libpng.)

[SkyLined, 2010-03-18 16:34:46]

LGTM, appart from the potential performance hit in the decoder.

http://codereview.chromium.org/1118002/diff/1/16
File third_party/libpng/pngrutil.c (right):

http://codereview.chromium.org/1118002/diff/1/16#newcode335
third_party/libpng/pngrutil.c:335: 0/*output*/, 0/*output size*/);
Seems to me like the code decompresses twice, once to determine the size of the
compressed data without storing the decompressed data and once after it
determines the size is within limits. This could cause a performance hit, do we
need to worry about that?

[agl, 2010-03-18 16:50:41]

http://codereview.chromium.org/1118002/diff/1/16
File third_party/libpng/pngrutil.c (right):

http://codereview.chromium.org/1118002/diff/1/16#newcode335
third_party/libpng/pngrutil.c:335: 0/*output*/, 0/*output size*/);
On 2010/03/18 16:34:46, SkyLined wrote:
> Seems to me like the code decompresses twice, once to determine the size of
the
> compressed data without storing the decompressed data and once after it
> determines the size is within limits. This could cause a performance hit, do
we
> need to worry about that?

I agree that this isn't great. It could probably be done better, but I think we
want the security fix so we should take this as is, and push a better solution
upstream.

[SkyLined, 2010-03-18 17:04:40]

On 2010/03/18 16:50:41, agl wrote:
> http://codereview.chromium.org/1118002/diff/1/16
> File third_party/libpng/pngrutil.c (right):
> 
> http://codereview.chromium.org/1118002/diff/1/16#newcode335
> third_party/libpng/pngrutil.c:335: 0/*output*/, 0/*output size*/);
> On 2010/03/18 16:34:46, SkyLined wrote:
> > Seems to me like the code decompresses twice, once to determine the size of
> the
> > compressed data without storing the decompressed data and once after it
> > determines the size is within limits. This could cause a performance hit, do
> we
> > need to worry about that?
> 
> I agree that this isn't great. It could probably be done better, but I think
we
> want the security fix so we should take this as is, and push a better solution
> upstream.

Okay, let's get this fix in. We should only end up decode each image once, after
we downloaded it or after the site has generated a data: url. Both downloading
and generating a data: url must be a bigger hit on performance than decoding
anyway, so I do not expect this to be noticable.