Re: CALL for DISCUSSION: cOMp/cOMP/coMp/coMP: compression wrapper chunks
John Bowler <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAP7U39-GEYifhgdUeVD-f7aTxWGFiQvJpKf7+QGJSk-4wi6_iQ@mail.gmail.com> |
On Sun, Jan 29, 2017 at 5:00 PM, Glenn Randers-Pehrson <[email protected]> wrote: >> ... A decoder shall discard a cOMp chunk >> containing an unsafe-to-copy original chunk and a cOMP chunk containing >> a safe-to-copy original chunk. > > > Shouldn't that say > > ... A PNG editor shall discard a cOMp chunk containing an unsafe-to-copy > original chunk but it may preserve a cOMP chunk contianing a safe-to-copy > original chunk, as explained in Chapters 3.3 and 7.1 of the PNG > specification > (Clause 14.2 of the ISO PNG Specification). No, it was describing decoder behavior. The behavior with regard to editors, which was correctly (IMO) removed to a separate clause, just works. The point is that, as an attacker, I can take an 'unsafe-to-gopy' PNG chunk and wrap it in a cOMp (safe to copy) chunk and maybe persuade an editor to put it somewhere dumb, but more likely persuade it to preserve it. At that point I have a PNG within an unsafe-to-copy chunk which is wrong, and maybe in the wrong place. So what? I can do this without cOMp. -- John Bowler <[email protected]> +1 (541) 450-9885 PO BOX 3151 KERBY OR 97531-3151 USA ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot