[rb-general] [jvm] How to share rebuilder attestations
hboutemy at apache.org
Sat Jan 5 08:00:49 CET 2019
Le jeudi 3 janvier 2019, 11:39:08 CET Daniel Shahaf a écrit :
> 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.
do you expect multiple signatures on 1 buildinfo file? ie multiple rebuilders
attesting a shared buildinfo file
or do you just expect 1 buildinfo file per rebuild?
> 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.
in such a scenario, instead of sharing a buildinfo in the rebuilders infra,
then a requirement for a process to differentiate the buildinfo files that
proove the rebuild is ok vs the buildinfo files that prove that there is a
reproducibility issue, I'd prefer an issue in a bugtracker
> 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.
I don't really get the example: trying to compare 2 different versions is not
about build reproducibility
I really think the key question is: do we expect multiple signatures on one
file, whatever this file is (the binary artifact or a buildinfo file
representing a typical build environment)? Then a hosting solution that has to
append to a .asc file
Or never expect multiple signatures, but only new files (then in this
scenario, the new files will be buildinfo files, because the reference binary
artifact is unique)?
> rb-general at lists.reproducible-builds.org mailing list
> To change your subscription options, visit
> To unsubscribe, send an email to
> rb-general-unsubscribe at lists.reproducible-builds.org.
More information about the rb-general