full-disclosure - avoid jpeg overflow problems using on the fly conversion?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: avoid jpeg overflow problems using on the fly conversion? 

On Fri, 17 Sep 2004 23:03:10 +1200, Nick FitzGerald said:

> And, your suggestion does not say what to do with "bad" JPEGs -- it 
> seems you assume the JPG to PNG convertor will necessarily and 
> "correctly" deal with such invalid input.  Do we really know that is a 
> valid assumption?

There's also another sticky issue - it seems at least one release of AOL's
"net accelerator" basically consisted of code that downgraded all the .JPG
to a higher-compression (therefore more lossy) format.  Some questioned
what this meant for places like corbis.com, who make money selling *high*
quality images.  Applying type conversions like this is always fraught with
unintended consequences... :)

Bonus points for figuring out how to make the filtering work if the
front-end points at an https: :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040917/d71c104d/attachment.bin