On 1/7/19 3:26 AM, Hervé Boutemy wrote: > this scenario is highly hypothetical if the buildinfo is thought as a > recording of current build environment, then generated > > I understand that you expect the vast majority to be 1 buildinfo per > rebuilder, which seems reasonable from a rebuilder perspective: it's the > attestation sharing solution that will have to deal with the risk to have > many > rebuilders requiring to publish many buildinfo files for 1 artifact (let's be > optimistic and tell that there will be thousands of rebuilders: it's not for > now, but that would be a sign of success)
In Arch Linux, we've settled on embedding the buildinfo into the binary artifact (packaged tarball), which solves several issues for us: - we only focus on attesting that a build can be repeated, not on how it can be smoketested with variations - ensures the buildinfo is always available, no exceptions - append your PGP signature for the package and sign both at once - no proliferation of buildinfo It also integrates nicely with existing packaging infrastructure we have, and there are plans in the works to leverage this to guarantee that all packages are built in chroots containing only officially published packages. > I'll precise that I'm trying to figure out how the workflow will happen for > binary artifacts published in JVM public repositories (like Maven Central or > Android Maven Repository): that may influence some ideas > While telling that, the case of Linux distros rebuilding JVM artifacts is > really a mix that I don't yet manage to see: if someone canshow me how JVM > artifacts are rebuild for Debian, for example, I'm interested... In Arch Linux we have a mixture of packages that just rebundle an existing binary, and packages that just run gradle/mvn in the source directory. As far as handling dependencies goes, I'm not sure we do much if any of that at all -- I'm not even sure how that would work for java. So I'd be interested in more perspectives on this as well -- especially if they have a reliable answer to the question of offline builds. As I understand it, the usual build workflow involves looking up dependent artifacts by querying an actual server instance and then downloading them. >> - Is a rebuild expected to reproduce the buildinfo file verbatim? > clearly not, since the buildinfo intent is to record the environment used > with > sometimes too precise data (like for example the patch level of the JVM used, > which in general is not really important AFAIK, or the OS that in general > should not be important in the JVM case) If the information is important enough to record, it might be important enough to make a difference in the outcome. If varying the JVM version is still desirable, I'd see this as mostly useful for the testing process, i.e. checking reproducibility issues and using diffoscope to see what changed. >> - What exactly gets PGP-signed? (The binary artifact? The buildinfo? >> If the latter, how does one then establish trust in the binary >> artifact?) > good question: > the rebuilders's buildinfo, for sure, gets signed by the rebuilder > Signing the binary artifact could make sense, but the workflow for that may > not be easy... > Signing the original buildinfo file to me does not really make sense: if we > sign an existing file, IMHO it's better to go with the binary artifact +1 The buildinfo doesn't need trust, it's the source recipe and you can prove it's the correct one by using it yourself to rebuild the artifact. Signing the build artifact tells you that the recipe worked, and it also makes it more straightforward to check the validity. (It drives me nuts as a distro packager to see upstream projects that provide a sha512sums file and PGP-sign the checksums, but don't PGP-sign the binaries. It's completely unfeasible to support the many ways this file can be created in a purely programmatic way, and the proliferation of signing data is difficult to standardize. If the source artifact itself is not PGP-signed, we simply don't support it and the package does not get PGP verification at all.) -- Eli Schwartz Bug Wrangler and Trusted User
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].
