Thanks for the discussion, Hans. On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote: > Packages should not be accepted into any official repo, sid included, without > some verification builds. A .deb should remain unchanged once it is accepted > into any official repo (maybe experimental could be an exception, but not > sid). I think that is essential.
But some repositories could have different rules for package inclusion than others, right? for example, say debian wanted to offer an unstable-reproducible suite, which only permitted packages that had been independently rebuilt reproducibly by multiple DDs and at least two different buildds. Ideally, the packages that are shared between this repository and other repositories would be identical. Note that if .deb files are internally signed, two developers *cannot* create the same exact .deb if they do not share their secret keys. > I see no reason for changing the .deb between sid and testing, except for > perhaps how existing implementations are doing it. It is usually worth the > work to do things right way, rather than the easy way. I agree with this sentiment, i think we're trying to sort out what is the "right way". > The build verification process needs to happen between the package upload and > publishing to sid or security updates. Two builds is easy: the .deb that the > uploader generates and the one the Debian process makes. That is probably > enough. > > In Debian's case, it probably is too complicated to include multiple > signatures. In that case, there should be only one canonical signature by dak > once the build verification signature threshold has been passed. Then all of > the other signatures could be added to .buildinfo or .changes or whatever > other file. but the .buildinfo file is designed to say "i generated the .deb that matches this digest exactly", which the corroborating builder cannot do, because they cannot produce the internal signature. Plus, we now have two different places to look for signatures. one "canonical" one and then some external ones, and the signatures themselves have different properties (one signs parts of the deb, the other signs the whole .deb; one signs the build environment, the other does not, etc) > Another option is to do it like f-droid.org does. F-droid.org generates a APK > signing key for each app, then manages the signing on a specialized signing > server. Or another option is just requiring all the signers to be from the > debian-keyring, rather than an exact match for previous signers. Again, i think this is getting ahead of the discussion. i'm not proposing that we try to set debian (or other derived distro) archive policy here, i just think we want to think > In any case, the .deb needs to remain unchanged. right. but it can't be unchanged if the archive distributor decides that a different signer is the "canonical" signer. So you're making the contents of the .deb dependent on archive policy, rather than the other way around. I *want* ubuntu and debian and mint to all ship the exact same .deb for any packages that are reproducible (and eventually, all packages!) that they share, and i also want those different distros to be able to produce the reproducible .deb independently of one another. If foo_1.2-3_mipsel.deb is built first on the ubuntu builders and ubuntu decides to include it in the archive, and then debian is able to reproduce that build and wants to include it in debian, these should be the same .deb file, even though the archive gating infrastructure is independent. > I think this can be done using the existing .deb format. This.debs approach > also requires a conscious opt-in: "we tell users and upstream developers that > if they want to install packages via sneakernet..." exactly, and i think this is a good thing. it's a clear external signal that they're transporting a signed object. Users can also sneakernet around arbitrary .tgz files, or .zip files, or .dmg's or whatever. we can't stop them from doing that, but we *can* say "if you want to sneakernet things around with any sort of cryptographic security, you should be sneakernetting things that look like *.debs, and nothing else". If we say "some .deb files might be signed, some might not, good luck with that" it's less clear. There is a long-standing, widely understood idea about what a .deb is. Changing that to be something that only a given party can generate goes directly against the goal of having builds be reproducible. We know that detached signatures allow us the flexibility to do all kinds of clever archive-decided policy while sharing a broad consensus about the byte-for-byte nature of any piece of compiled code. Detached signatures fail at ease of manual transport. Introducing a package wrapper that includes signatures to facilitate manual transport seems like the way to solve that problem, rather than having to embed or privilege any one canonical signature above another, or introduce two different-yet-similar mechanisms for individual binary package signing and verification. --dkg
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds