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

[Daniel Shahaf]

Hervé Boutemy wrote on Mon, Jan 07, 2019 at 09:26:44 +0100:
> Le dimanche 6 janvier 2019, 20:10:50 CET Daniel Shahaf a écrit :
> > I think the questions, at this point, are:
> > 
> > - Is a rebuild expected to reproduce the binary artifact verbatim?
> AFAIK, the objective of rb is to answer: yes
> isn't it?
> to avoid manual inspection of the output to decide whether the result is safe 
> (just reproducibility bugs) or not (what we really chase = binary that contain 
> code that is not in the source)

Bit-for-bit reproducibility should be our goal, but it's not a _sine qua
non_.  In a pinch, out of pragmatism, one can get by with less.  For
example, if there were some binary package whose rebuilds are identical
up to the copyright year in the commented header of some script file,
that'd be workable.  The process of comparing two binaries to confirm
they match would be more expensive, and the probability of false
positive comparisons (binaries that compare equal but aren't) higher,
but that doesn't make that package _insecure_; it merely makes it _less
secure_.  (Security isn't a binary dimension.)

> > 
> > - Is a rebuild expected to reproduce the buildinfo file verbatim?
> clearly not, since the buildinfo intent is to record the environment used with 
> sometimes too precise data (like for example the patch level of the JVM used, 
> which in general is not really important AFAIK, or the OS that in general 
> should not be important in the JVM case)
> 

Agreed.  (I misunderstood you upthread then.)

> > 
> > - What exactly gets PGP-signed?  (The binary artifact?  The buildinfo?
> >   If the latter, how does one then establish trust in the binary
> >   artifact?)
> good question:
> the rebuilders's buildinfo, for sure, gets signed by the rebuilder
> Signing the binary artifact could make sense, but the workflow for that may 
> not be easy...
> Signing the original buildinfo file to me does not really make sense: if we 
> sign an existing file, IMHO it's better to go with the binary artifact

Once again I disagree.  A rebuilder _can_ sign the both the input
buildinfo file and the output buildinfo file, *provided that the
signature explains that difference*.  For example, suppose I get this
input buildinfo file:

    # File A: input buildinfo
    Package-filename: hello-1.0.tar.xz
    Checksum: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    Build-on: FreeBSD

then I rebuild and produce some binary package (not shown) and an output
buildinfo file:

    # File B: output buildinfo
    Package-filename: hello-1.0.tar.xz
    Checksum: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    Build-on: Debian

then there is nothing stopping me from signing a statement to the effect
of "I have successfully rebuilt File A, a buildinfo file whose full
contents is <such and such>".  The data model simply needs to be
designed in such a way that verifiers know whether a signature on a
buildinfo file means that I _produced_ it or that I _attest_ to it.

Of course, even if I attest-sign File A, I should still produced-sign
File B.

Cheers,

Daniel