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

Mon Jan 14 15:11:59 CET 2019

On 1/13/19 3:07 AM, Hervé Boutemy wrote:
> Le mercredi 9 janvier 2019, 18:06:23 CET Lukas Puehringer a écrit :
>> ...
>> 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?At the summit we briefly talked about if (and how) one rebuilder should
provide multiple rebuilds of the same source code, and how they may be
used for verification. Should the verifier consider all corresponding
attestations? Do they have to agree on the result? Should there be a
threshold of agreeing attestations? ...

To me this feels like a specialization of what we already do, that is
comparing multiple attestations from different rebuilders.

Is there a benefit from having one rebuilder rebuild the same source
code repeatedly? *Bad* results should be caught just as well by
comparison with other rebuild results.

That said, if there are good reasons to have one rebuilder do multiple
rebuilds of the same source code, it should be easy to adapt the API
accordingly. However, in-toto link metadata files are not meant to
accumulate multiple results from different activities (or different
occurrences of the same activity).

> 
>> ...
>> 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
Yes, although our objective is not metadata that serves both as recipe
and as attestation of rebuilds. Instead we want to define a generic
format that provides evidence for any step in the software supply chain
and that can be used to link all the steps together (hence the name link
metadata).

>> ...
>> 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... 

You are right, the rebuilder/apt setup is one Linux-distro specific
implementation of how to generate and publish rebuild attestations.
However, our proposed metadata format and verification protocol works
independently of how attestations are generated, aggregated and distributed.

> 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.
That sounds like a good plan.

Cheers,
Lukas

> 
> Regards,
> 
> Hervé
> 
>>
>> Thanks,
>> Lukas
>>
>>
>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__pad.riseup.net_p_reproduciblebuilds4-2Dagenda&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=2YMLsMLCML1EOEAeVc1Mhx6J99vqRVHSnZUnatehIDg&m=hPYzuRrB6X7y5hsVRG7X6vtXL22bzEw4BUERiTdLVO0&s=lY2dEROSzckn2GXAeOxuPtjbnnJwrk99kbrvQwsvK0o&e=
>> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_in-2Dtoto_apt-2Dtransport-2Din-2Dtoto&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=2YMLsMLCML1EOEAeVc1Mhx6J99vqRVHSnZUnatehIDg&m=hPYzuRrB6X7y5hsVRG7X6vtXL22bzEw4BUERiTdLVO0&s=FAWxzyBzVZb5ZcLQcOIIKAEU_t41d7zgh22ogdJmRsY&e=
>> [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jenkinsci_in-2Dtoto-2Dplugin&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=2YMLsMLCML1EOEAeVc1Mhx6J99vqRVHSnZUnatehIDg&m=hPYzuRrB6X7y5hsVRG7X6vtXL22bzEw4BUERiTdLVO0&s=q6ZU7zHtueMcJDiVHw6ECoKuV9PWbvbudNXJuA0bFr8&e=
>>
>> 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.
> 
> 
> 
> 
> _______________________________________________
> 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=hPYzuRrB6X7y5hsVRG7X6vtXL22bzEw4BUERiTdLVO0&s=VsCmRrUBW0FgiWFm2Jk7BK7zwCLuzH2kcDTraaVjFx4&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/20190114/4c3c6b13/attachment.sig>