Nils Philippsen <nils <at> redhat.com> writes: > But that's not what you described in the original posting (emphasis on > "no bad ones"): > > """ > > With this we could then require N good signatures (and no bad ones) on > > each package before yum would trust the content. > """ I did not say that yum should use another one. The distribution system in charge of accepting signatures would discard bad ones. The package would have to be signed by someone else before distribution and before yum would trust it. Just a slight delay, that's all. > The Matt or whoever else has a separate build system are the only > valuable signatories. Anybody else can only say "me too" but that > doesn't add anything to the trust value. I don't think that's right. As long as you have something independent to compare to, it is not just one person that can run the comparison. If you spread the effort to more people, you lower the load. > No, without independent verification builds, an attacker just has to > break the build system because a normal packager has no (sensible) way > to tell if e.g. a compromised compiler inserted trojan code into the > executables. Thus, a normal packager -- trusting what comes out of the > build system -- would just sign off whatever the resulting package is. I did not say that packagers would be signing the packages. I said that signatories would be doing that. Having independent verification builds is a must, because signatories would make sure builds match. > As independent verification builds aren't the deterministic thing that > you seem to think, that doesn't sound very helpful to me. Well, just because we base our build comparisons right now on something as crude as raw checksums, doesn't mean this has to be like that forever. We may find ways of comparing builds differently to determine if they were compromised, by explicitly excluding well known differences within binaries. > It's like with spam filtering: bad positives are really bad. Do you > think repeating the hoopla of the last days just because of a bad > positive caused by a fluke in an independent build system we have no > control over is a good thing? The hoopla of the last few days would not be repeated. There would be no danger to users, because multiple signatures would be required to inject a bad package into users' machines. That's kinda the point of double checking. Nothing would have to be taken down immediately and reinstalled. > Our packages built in say OpenSUSE's or Ubuntu's build system will > differ from what koji spits out, with a probability bordering on > certainty. I don't know what that gains us. I didn't say SUSE or Ubuntu folks would have to build Fedora packages on their build systems, just their build farms (i.e. machines). Isn't koji open source? If it is, they could run that just fine. But hey - I get it, people don't like the additional hassle. That's OK. Consider my proposal withdrawn until the time someone invents a way of reliably comparing two independent builds. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
