Differences between revisions 3 and 4
Revision 3 as of 2016-10-10 11:59:23
Size: 3761
Editor: Infinity0
Comment: add security considerations
Revision 4 as of 2016-10-10 14:14:57
Size: 3827
Editor: Infinity0
Comment: add a diagram
Deletions are marked like this. Additions are marked like this.
Line 26: Line 26:
{{attachment:actors.png}}

source: [[attachment:actors.dot]]

Discussion with ftpmasters is happening in 763822.

Overview

The characters in our story:

Servers:

  • One 1 archive. This accepts signed-buildinfo files from developers, and publishes a small collection of re-signed-buildinfo files to rebuilders and non-building clients.

  • Several sig-repos ("signed-buildinfo repository"). These accept signed-buildinfo files from developers and rebuilders, and publish all of those that they accept to clients. They are very similar to PGP keyservers, but instead of holding signatures-on-keys (and keys), they hold signed-buildinfo files. Eventually these could submit their contents to, or be, one or more transparency logs.

Clients:

  • Many developers, who generate signed-buildinfo files and push them to an archive and the sig-repos.

  • Many rebuilders. These pull data from the archive, attempt to reproduce the builds, then generate signed-buildinfo files and push them to the sig-repos (c.f. the workflow of developers). Some might be continuous integration services, some might be manually-run.

  • Many non-building clients. Theses pull data from the archive and the sig-repos, to gain confidence that what they install is reproducible, without rebuilding it themselves.

Guide to verbs:

  • Push-servers accept things from clients that push to them.

  • Pull-servers publish things to clients that pull from them.

actors.png

source: actors.dot

Rationale

Security considerations

Due to resource constraints - i.e. a design optimised for binary distribution but not signature distribution - archives are not expected to store buildinfo signatures by the original developer. Instead, they can re-sign a whole batch of buildinfo files at once, after doing basic sanity checks on them - e.g. to check that the developer isn't lying about them - and publish this. One may raise the point that this batch is redundant given the sig-repos, but actually they can help to avoid some attacks:

  • Fake buildinfo files presented as "from the archive". Yes, these would not be signed by the archive - but if the archive does not officially publish a signed version, there is no way to distinguish a legitimate one vs a fake one.

  • Sig-repos getting ?DoSd by buildinfo files for junk. They may instead filter only for buildinfo files that build a source package that was actually published by the archive. Of course, they MUST accept (subject to self-protection vs DoS) buildinfo files with binary hashes that contradict what the archive said - that is the whole point of reproducible-builds.

To prevent the archive framing them for generating a false or bad buildinfo file, developers MUST publish their own signed-buildinfos to a (or several) sig-repos. Developers must do this directly from their own machines, rather than relying on the archive to forward this - since the archive could just drop it, if they are being malicious. Again, yes nobody can forge the developer's signature on a buildinfo file, but if there is no signed version in public distribution, then there is no way to distinguish a legitimate one vs a fake one.

We do not yet attempt to define what sort of logic non-building clients should perform, in order to classify a "safe" vs an "unsafe" binary. This (a) does not affect the rest of our system, and (b) is a hard problem to solve, and would require more real-world data and research. The strictness of the policy will depend on the user's security needs.

  1. "One" means in the sense of who controls the keys; there might be a CDN or mirror network that duplicates the contents. (1)