[Reproducible-builds] Bug#777251: rst2pdf: incorrect monkey-patching of PDFDate causes non-reproducible output

[Chris Lamb]

Source: rst2pdf
Version: 0.93-4
Severity: wishlist
Tags: patch
User: reproducible-builds at lists.alioth.debian.org
Usertags: toolchain randomness
X-Debbugs-Cc: reproducible-builds at lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that rst2pdf can generate PDFs with non-determinstic output.

What happens is that because the monkey-patched PDFDate does not extend
PDFObject, when Reportlab goes to format it:

    # reportlab/pdfbase/pdfpattern.py

    if isinstance(x,strTypes):
       L.append(pdfdocEnc(x))
    elif isinstance(x,PDFObject):
        L.append(x.format(document))
    else:
        # [..]
        L.append(pdfdocEnc(str(value)))

... we don't call .format(), but rather we end up calling str(..) on the
our monkey-patched instance, returning a value such as:

    "<rst2pdf.createpdf.PDFDate instance at 0x7fc7cd56b320>"

This string gets embedded into the final PDF via the CreationDate PDF
metadata and, as the embedded memory address is non-deterministic, it
results in non-reproducible output.

The attached patch simply specifies PDFObject as the parent class so we
take the right branch in the above code. Once applied, various packages
can then be built reproducibly in our current experimental framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org / chris-lamb.co.uk
       `-
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff.txt
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150206/e32ecba0/attachment.txt>