bug#27563: [PATCH v3 2/2] gnu: ghostscript: Write document ID only when encrypting.

[Leo Famulari]

On Fri, Jul 07, 2017 at 03:21:49PM +0200, Danny Milosavljevic wrote:
> Yeah, at the upstream bug link
> <https://bugs.ghostscript.com/show_bug.cgi?id=698208> we discussed
> that (somewhat).  While they don't want to carry the patches (because
> they don't want to lose functionality) they explained that it might
> well be that *future* versions of the spec could make ID and UUID
> mandatory.
> 
> Right now there's a stringent spec, called PDF/A (for "archiving";
> which is intended for governing bodies where you don't want existing
> documents that dynamically alter their contents after some time - like
> with Javascript or something) which already sets the instance UUID to
> "".  So I just set it to "" always rather than just for PDF/A.
> 
> Also, as far as I understand the "/ID" is currently only mandatory
> when encrypting, although in the future it might change.
> 
> That leaves the document UUID - and upstream, in some of the other
> bugreports, explained that they want UNIQUE document UUIDs.  So I
> figured that we should just leave it off - so it's not the same over
> multiple documents.  They are definitely not fine with non-unique
> UUIDs.
> 
> This RDF metadata stuff (the instance UUID and document UUID) is quite
> new.  In a former life I wrote PDF parsers and I didn't handle the RDF
> back then at all.  So I guess it would even work to leave the entire
> RDF metadata off - after all, it worked back then.
> 
> If someone is well-versed in XMP RDF metadata for PDF, I wonder what
> is better: leaving the entire RDF off or just leaving the element
> containing the document id (as an attribute) off.  Currently, the
> patch does the latter.  The specification by adobe (XMP Specification
> Part 1, ISO 16684-1:2011(E) Annex A) says "The use of robust GUIDs is
> encouraged; having globally unique values is important" but as far as
> I can see doesn't say whether they are mandatory.
> 
> I also thought of patching groff instead.  But it seems that groff is
> now searching for a maintainer - I'm not sure anyone would integrate
> it there.  Also, I'm not well-versed in perl.  Also, patching finished
> PDFs (using regexps or something) is kinda dangerous because nobody
> *forces* you to encode the streams (think: attachements) in PDFs.  So
> it could be that some other non-PDF thing is integrated into the PDF
> as a stream and the regexp substituter would just substitute it in
> there as well.
> 
> There's a program "pdfmark" which is supposed to be for changing the
> metadata for PDFs but upstream said that it can't change those fields.
> It could change the CreationDate, ModDate etc.
> 
> In short, I think the lowest risk is patching ghostscript as we did
> here.

I think the lowest risk is to do nothing to Ghostscript and move the PDF
documentation to a separate 'doc' output. Then, we could have
reproducible binaries and ignore the PDF issues for now. Does anyone
know how many packages include PDF documentation built with Ghostscript?

I think the next lowest risk is to do nothing.

I think it's risky to patch Ghostscript, for a few reasons:

1) The patches don't include provenance information, so it's difficult
to find any other discussion of them. I'd like for the Ghostscript
maintainers to have reviewed the proposed changes, both for code
correctness and for PDF-specific issues.
2) At least some of the patches in the related Ghostscript discussions
seem to be proof of concepts rather than finished code:
https://bugs.ghostscript.com/show_bug.cgi?id=697484#c3
So, if these patches came from there, we'd want to be extra careful.

By the way, this is the patch used for Debian's latest Ghostscript
package:

https://anonscm.debian.org/git/printing/ghostscript.git/tree/debian/patches/2010_add_build_timestamp_setting.patch?id=e2bf3ad7026afe13636d4937430c3fdae7854078

That patch was not reviewed on a public forum, at least nothing I can
find with Google. Again, I'd want to get the Ghostscript team's advice.

signature.asc
Description: PGP signature