Re: Time to resurrect multi-key signatures in RPM?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux