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

[Eli Schwartz]

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

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