3761
Comment: add security considerations
|
3827
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.
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.
"One" means in the sense of who controls the keys; there might be a CDN or mirror network that duplicates the contents. (1)