From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: bug#27563: [PATCH v3 2/2] gnu: ghostscript: Write document ID only when encrypting. Date: Fri, 7 Jul 2017 12:21:51 -0400 Message-ID: <20170707162151.GA17441@jasmine.lan> References: <20170703200844.3f6d9e19@scratchpost.org> <20170706103216.25939-1-dannym@scratchpost.org> <20170706103216.25939-3-dannym@scratchpost.org> <87podca20z.fsf@gnu.org> <20170707152149.3235f3aa@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTW15-0006wp-Ar for bug-guix@gnu.org; Fri, 07 Jul 2017 12:22:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTW14-0001nV-1X for bug-guix@gnu.org; Fri, 07 Jul 2017 12:22:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:54293) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dTW13-0001nP-Td for bug-guix@gnu.org; Fri, 07 Jul 2017 12:22:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dTW13-0006A8-O7 for bug-guix@gnu.org; Fri, 07 Jul 2017 12:22:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <20170707152149.3235f3aa@scratchpost.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Danny Milosavljevic Cc: 27563@debbugs.gnu.org --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 07, 2017 at 03:21:49PM +0200, Danny Milosavljevic wrote: > Yeah, at the upstream bug link > 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. >=20 > 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. >=20 > Also, as far as I understand the "/ID" is currently only mandatory > when encrypting, although in the future it might change. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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=3D697484#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=3De2bf3ad7026afe13636d4937430c3f= dae7854078 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. --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAllftRsACgkQJkb6MLrK fwjt1w//edarixU7iOy9WogdWSU/FaFs0asr0tI3w9t07mDD0TmL6jG4mZZsKPgf 5lrprSf+HlJE1kq/QBHOBzoAQPufF8DMnYKlfAKUzfEL484Mc0gzV2Xlk0QV0YYo XJXiaGPBxqXbKUqroqFavQk3NGCPwgbq42mn+u6zi6NYVwfzmLWdcUIwpef7Zqjc JH5gP1vl4fBmz/2vB2mgfwO/HQc8GlrhcpVNwmeLIT3ZpxgdBAzutBDS4qz1HMxO BizEImz0Ndmgtv3To4/RiLUnUzqDp02yVK6N6vG8tiNIucZy/9AoVRB2Khiw12Hh rwGXgemvNPbOhSmqSwiVfTWGLVx4m3TrxgyADhmjPYrIggAqKovUMS0PRLrsSVi0 qJ6JE4GWPDlqDqYIHOWIOu35Ydj/dJtxTrw/8VqSAKqaBtSzuhOSpwa730XsV8fY 6vzKyungot/U2kRm3fezVwIb9OSWArG00k4hvmINp/R4KhHHoYG/ZA4XjIJn9kCD BSDU3Ljn4/fPWs9ynyP5G/FjZqnfMTXvmCbGAihGPY2SKHoqQ9YVWuNx1XhPF5vY Vy7lWCK14KHnIEF4qHFHtCzPa5FrQ6Ow42uLkQtCfLNA7GEMwG0V64kyfkcTLkrK OF3g6r5HfWMNkSU1GVyHedmMqgaCJQndVeGVHl249vLbsgocM0M= =XhiP -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--