[rb-general] [jvm] How to share rebuilder attestations

[Daniel Shahaf]

Hervé Boutemy wrote on Thu, Jan 03, 2019 at 09:21:49 +0100:
> Le mercredi 2 janvier 2019, 13:11:43 CET Arnout Engelen a écrit :
> > Having each successful rebuilder append his signature to a shared .asc
> > would indeed be elegant
> +1
> 
> > when we can expect the .buildinfo for the
> > original build to always be identical to the .buildinfo of any
> > rebuilder.
> yes, what to sign? buildinfo?
> if buildinfo was a pure specification of the instructions to rebuild and only 
> that, signing them would be ok.
> But buildinfo is currently also a recording of an environment used to build = 
> something that I don't expect to be reproducible in the JVM world: we're not 
> in a Linux distribution case, I'd like to keep some flexibility to rebuild

When multiple .buildinfo files attest the same binary artifact, there is
no need for them to be identical; each .buildinfo file *individually*
needs to be cryptographically signed and cryptographically linked to the
artifact it attests, but it's perfectly reasonable to have one binary
artifact backed by six different .buildinfo's and six different
.buildinfo.asc signatures.

Furthermore, there are benefits to that, too: it can help trace
reproducibility bugs.  For example, suppose six buildinfo files were
generated in 2018, and then a seventh buildinfo appears that was
generated in 2019 and has a different checksum; that could indicate
a missing use of SOURCE_DATE_EPOCH somewhere in the build process.

That's from the end user's point of view.  From the packager's/rebuilder's
point of view, the fact that the .buildinfo contains information not
necessary for reproducing the file is not, by itself, a reason not to
sign it.  For example, if I generate an email message and it contains a
non-standard "X-Composed-On: Debian" header, I would go ahead and sign it
anyway, since I don't disavow the fact that I run Debian.  Users will
verify the rfc822 message successfully and simply ignore the X-* header
they don't know/care about (as rfc822 says they may).

> Why not signing the output artefact?
> = attesting: "I was able to produce such a binary" (and I don't tell precisely 
> how my build environment was near from the official one)?

The answer to this hinges on whether collisions — i.e., two
*substantively* different .buildinfo files that happen to generate
identical artifacts — are possible.  I can imagine such cases:

Suppose somebody releases foo-1.0.0 and then foo-1.0.1 where the only
change is that one of the generated Perl scripts shipped in the binary
package has one more line when binary package is for Linux systems.
Suppose further somebody builds foo-1.0.1 for BSD systems and signs it.
You wouldn't want a Linux user who runs into that artifact to succeed in
verifying it: on BSD the binary artifacts foo-1.0.0 and foo-1.0.1 are
identical, but on Linux they wouldn't be.