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

[Hervé Boutemy]

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)?

Regards,

Hervé

> _______________________________________________
> rb-general at lists.reproducible-builds.org mailing list
> 
> To change your subscription options, visit
> https://lists.reproducible-builds.org/listinfo/rb-general.
> 
> To unsubscribe, send an email to
> rb-general-unsubscribe at lists.reproducible-builds.org.