Re: Maker data
John Bowler <[email protected]> Sun, 26 Feb 2017 17:58:49 -0800
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAP7U399KxyahyifEWD9n+mEdEOJ8svKqEp8jMFwEnL-pEKPNYA@mail.gmail.com> |
On Sun, Feb 26, 2017 at 12:01 PM, Pavel Zlatovratskii <[email protected]> wrote: > By "unsafe to modify" I mean that EXIF (unlike other chunks) consist of > many independent values. And by modifying one kind of values (e.g. > adding water depth or removing body serial) you may break other kind of > values (MakerNote data). Like if changing ICC Profile name would make it > unreadable. Well, that's what an EXIF library handles, just as lcms handles interdependencies in ICC profiles. However if you separate parts of the EXIF data into separate chunks there is no way of preventing a *valid* PNG application deleting or, possibly, modifying the relevant values. > Also your conditions does not prohibit dependence between ancillary > chunks if The rules I expressed were for handling chunks that are *not* recognized. If an app recognizes a chunk those rules do not apply to the recognized chunk. Knowing that all the applications in the workflow completely obey the PNG spec *and* don't have any bugs apparently allows you to specify a set of constraints to allow your separate chunks to have inter-dependencies. However, in practice, your rules are so complex that it is easier to simply say that anything that uses the chunks has to make sure they are correct! > As for actual (yet partial) example dSIG looks like depends on all > chunks incl. ancillary, but invalidated after any modification. A completely conformant PNG editor may preserve a dSIG chunk *AND* that chunk will, likely as not, be invalid. This is my point; dSIG can be made invalid by a *valid* edit. The issue was known when the chunk was proposed; all it does is detect modification (any modification) of the PNG stream. The proposers wanted to be able to embed a secure signature within a PNG and didn't need any guarantee that it was correct (since the dSIG data does that itself.) -- 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