Hi everyone, 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/metadata. 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. 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. 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? 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 > _______________________________________________ > [email protected] mailing list > > To change your subscription options, visit > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.reproducible-2Dbuilds.org_listinfo_rb-2Dgeneral&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=2YMLsMLCML1EOEAeVc1Mhx6J99vqRVHSnZUnatehIDg&m=ESGEOKGZ_1VxOOIJQtOoiq9K23E41v65somsn2H1rqQ&s=H8NSOJd-pvuTE1X0Pw0Y8mu26M35MaDhBhUJQSpMx9I&e=. > > To unsubscribe, send an email to > [email protected]. > -- [email protected] PGP fingerprint: 8BA6 9B87 D43B E294 F23E 8120 89A2 AD3C 07D9 62E8
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list To change your subscription options, visit https://lists.reproducible-builds.org/listinfo/rb-general. To unsubscribe, send an email to [email protected].
