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 > > _______________________________________________ > > [email protected] 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 > > [email protected]. _______________________________________________ [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].
