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