The recent addition of 1.4.0 of the PNG extensions document to
libpng.org(and 1.4.6 of the registered chunks) added 'dSIG'.
Handling this chunk correctly is a little tricky.
The chunk is specified to occur in matching, possibly nested, pairs with
one of the pair immediately after IHDR (or an enclosing dSIG) and the other
immediately before IEND (or the enclosing dSIG).
That sounds simple but section 14.2 ("Behavior of PNG editors") of the ISO
spec says this:
"(c) A PNG editor is always allowed to copy all unrecognized ancillary
chunks if it has only added, deleted, modified, or reordered
implies that it is not permissible for ancillary chunks to depend on other
and, effectively paraphrasing the above:
"(b) When copying an unknown *unsafe-to-copy* ancillary chunk, a PNG editor
shall not move the chunk relative to any critical chunk.* It may relocate
the chunk freely relative to other ancillary chunks that occur between the
same pair of critical chunks*. (This is well defined since the editor shall
not add, delete, modify, or reorder critical chunks if it is preserving
unknown unsafe-to-copy chunks.)"
Italics added by me, bold is in the spec.
In other words while the leading and terminating dSIG chunks must not be
moved across the intervening IDAT (or PLTE if present) they can be moved
relative to each other and to other ancillary chunks *and the result is a
Indeed many (most?) libpng using editors will do this if there are known
ancillary chunks present because inside pngwrite.c 'write_unknown_chunks'
is called *after* the code to write any known before-PLTE chunks.
This means that libpng can't do any special checking for dSIG. Indeed I
can't see a lot of point in adding any handling to libpng since, in the
absence of the library code to calculate the message digest, the chunk is
just a bag of bytes.
John Bowler <john.cunningham.bowler@...>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
On Sat, Dec 14, 2013 at 7:21 PM, John Bowler <
> In other words while the leading and terminating dSIG chunks must not be
> moved across the intervening IDAT (or PLTE if present) they can be moved
> relative to each other and to other ancillary chunks *and the result is a
> valid PNG*.
That's correct. But a dSIG processor will detect that someone has changed
the signed portion of the file, thus invalidating the signature. That
behavior seems OK to me.
Get latest updates about Open Source Projects, Conferences and News.