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

[Lukas Puehringer]

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
> _______________________________________________
> 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-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 rb-general-unsubscribe at lists.reproducible-builds.org.
> 

-- 
lukas.puehringer at nyu.edu
PGP fingerprint: 8BA6 9B87 D43B E294 F23E  8120 89A2 AD3C 07D9 62E8

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20190109/3ac2c0c5/attachment.sig>