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

[Hervé Boutemy]

Le mercredi 9 janvier 2019, 18:06:23 CET Lukas Puehringer a écrit :
> Hi everyone,
Hi Lukas,

> 
> in Paris we talked some about an API for rebuild attestations (see notes
> from "Rebuilder" and "Trust models" sessions [1]). From what I remember,
> it was not all that clear if every distro/project would have to come up
> with their own API or if the reproducible builds community can provide
> something that may be picked up by many.
> 
> For what it's worth, we run rebuilders at NYU and University of Bergen
> that serve rebuild attestations for Debian packages by their full
> versions, e.g.: A rebuild attestation for "jaxws_2.3.0.2-1_all.deb" is
> available at the endpoint
> https://reproducible-builds.engineering.nyu.edu/sources/jaxws/2.3.0.2-1/meta
> data.
> 
> Whether or not to provide distinct attestations on patch version level
> is one question. I'd say, if we end up with thousands of publicly
> accessible rebuilders, it should be possible to rebuild everything.
one question I have is: what would be the url for multiple rebuilds? Would 
multiple rebuilds of the same package provide separate buildinfo files but 
only one metadata containing multiple key ids and signatures?

> 
> A different set of questions, which I see in this thread and also saw at
> the summit, concerns the attestation format and the verification protocol.
> 
> We use metadata (see link above), which is similar to .buildinfo but
> more agnostic to the activity. That is, the same format used to attest
> for reproducibility can be used to attest for other things too.
this metadata looks like an extraction of a view fields that you find the most 
interesting for your activities

> 
> The important thing is that it provides verifiable evidence that an
> activity took place, that activity had some inputs (e.g. source files
> and an input .buildinfo) and produced some outputs (e.g. a binary and an
> output .buildinfo), and someone is vouching for the activity with a
> cryptographic signature.
> 
> Similar to the .buildinfo file, our metadata may carry environment
> information, e.g. to accommodate special use cases. Note that this extra
> information does not break the tolerant reader pattern during verification.
> 
> The verification protocol takes a set of policies and verifies that the
> desired amount of attestations is available, they were provided by
> trusted rebuilders, and they all agreed on their results.
> 
> Verification could be done by a plug-in on the package manager client,
> something we built for apt [2].
> Although our setup is tailored for Debian packages, the same generic
> metadata (we call it *link metadata*) and verification protocol should
> work fine with any project.
> 
> For instance, there is a native Java implementation that already
> produces link metadata as part of a Jenkins plugin [3].
> 
> Would this be applicable to your case?
everything looks very Linux-distribution centric.
What I see in the jvm world is that it is more repository centric. And inside 
a repository, there is no common build environment, since each artifact 
provider is independant: then we don't have the consistent distribution-
specific rebuild instructions required to rebuild.

IMHO, the "repository centric" rebuild instructions is what we need first, and 
that's the intent we have with our jvm buildinfo format: perhaps we should not 
call it buildinfo... 
Then once we will be on rebuild attestations, we should probably be able to 
reuse your tooling, since a jvm repository can be seen as a distribution 
resulting packages collection with a specific directory layout.

Regards,

Hervé

> 
> Thanks,
> Lukas
> 
> 
> [1] https://pad.riseup.net/p/reproduciblebuilds4-agenda
> [2] https://github.com/in-toto/apt-transport-in-toto
> [3] https://github.com/jenkinsci/in-toto-plugin
> 
> On 1/9/19 9:29 AM, Daniel Shahaf wrote:
> > Hervé Boutemy wrote on Wed, 09 Jan 2019 08:30 +0100:
> >> Le lundi 7 janvier 2019, 14:39:35 CET Daniel Shahaf a écrit :
> >>> 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*.
> >> 
> >> I don't get what you mean by a signature explaining a difference: when
> >> signing, is there some feature to add extra text (that would contain the
> >> explanation)?
> > 
> > I don't know if OpenPGP has such a feature, but it doesn't matter.  You
> > could, do something along these lines:
> > 
> > % rebuild input.buildinfo --output-file-name=output.buildinfo
> > % if buildinfos-match input.buildinfo output.buildinfo; then
> > 
> >     (printf '\0'; cat input.buildinfo) | gpg --detach-sign -o
> >     input.buildinfo.attestation-asc (printf '\1'; cat output.buildinfo) |
> >     gpg --detach-sign -o output.buildinfo.production-asc>   
> >   fi
> > 
> > And yes, that's a very minimal example, but it illustrates the principle:
> > define a file format that securely provides the additional information.
> > 
> > Cryptographic signatures do exactly one thing:  they link a document to
> > a principal.  One can build various semantics on top of that.  For that
> > matter, one could define a protocol that uses cryptographic signatures
> > to say "I have tested the subject file and I proclaim that it contains a
> > virus".
> > 
> > Cheers,
> > 
> > Daniel
> > _______________________________________________
> > rb-general at lists.reproducible-builds.org mailing list
> > 
> > To change your subscription options, visit
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.reproducible-2
> > Dbuilds.org_listinfo_rb-2Dgeneral&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=2YML
> > sMLCML1EOEAeVc1Mhx6J99vqRVHSnZUnatehIDg&m=ESGEOKGZ_1VxOOIJQtOoiq9K23E41v65
> > somsn2H1rqQ&s=H8NSOJd-pvuTE1X0Pw0Y8mu26M35MaDhBhUJQSpMx9I&e=.
> > 
> > To unsubscribe, send an email to
> > rb-general-unsubscribe at lists.reproducible-builds.org.