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 >>> _______________________________________________ >>> [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://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 > [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].
