On 09/22/2014 04:06 PM, Hans-Christoph Steiner wrote: > I think we're starting to nail down the moving parts here, so I want to > outline that so we can find out the parts where we agree and where we > disagree. > > * I hope we can all agree that the package itself should not change once it > has hit the official repos. > > * I believe we can achieve what we want without taking a shortcut and > introducing a new core package type (.sdeb .debs or whatever). We can figure > out how to do this with the .deb file. Personally, I would accept a new > package type after a thorough exploration of keeping .deb fails to deliver, > but not before. > > * There should be at least one verification build before a package becomes > official. > > * Then there needs to be a channel for people to submit the results of their > own builds. That could be only positive results or only negative results, or > both. > > * the .buildinfo file should contain all info needed to reproduce the build, > given a standard Debian build environment
Thanks, the above is a very useful summary. > Anything I left out? I think the summary above hints at but doesn't answer the question of what an "official" package means, and the fact that there may be multiple repositories (possibly operated by different organizations) with different rules about what should make a package "official". I think we need to ask whether we care about byte-for-byte identical .deb files *across* different repositories or not. If we don't care about cross-repo (or cross-organization) byte-for-byte reproducibility, then an embedded signature in the .deb might be acceptable (though the data it contains would be redundant to signatures over the buildinfo files, which would eventually be necessary for external policies or corroboration anyway). If we *do* decide that we care about cross-repo byte-for-byte compatibility, then embedding a signature in the .deb suggests that one repo can act as the gating factor for another, because repos collaborating in this reproducibility push cannot both hold the key that makes a .deb "official". I don't think that's a good tradeoff. As tempting as it might be to try to cement debian's "authoritative" role via such a lock-in, i'd much rather than debian derivatives, blends, side projects, etc, can all take initiative that can then be absorbed back into debian cleanly and reproducibly. i also suspect that the redundancy between internal signatures and signed .buildinfo records is likely to cause some increase in confusion, but i don't think that's as serious of a problem as the question of which signing keys get to be "authoritative". --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds