Time to resurrect multi-key signatures in RPM?

Bojan Smojver bojan at rexursive.com
Wed Aug 27 04:08:42 UTC 2008

Stephen John Smoogen <smooge <at> gmail.com> writes:

> There is a specific "named" fallacy to that logic. I can't remember
> the mathematical name for it, but basically the issue is that having
> multiple sources doesn't help if they all get their information from
> the same top level source.

Yeah, no kidding.

The point of open source is supposed to be that more eyes see better. That's why
we have package reviews, pre-release checks (alpha, beta, rc) and so on. You can
never achieve 100% independence, of course. That's why we have bugs :-)

> The big issue with multiple signatures is
> that they are going to be automated somehow to deal with the thousands
> upon thousands of packages being dealt with...

If there is any chance of this being automated, it cannot work at all and there
is no point doing it.

> and you are going to
> have to come up with an additional income source to pay for the extra
> bureaucracy that is being added.

True. All security has a price.

> Or just be in the right place somewhere.

More than one, actually.

> The build systems will not be
> completely independent or they would not be able to produce identical
> binaries..

Say someone breaks into Fedora build system and subverts the process in such a
way that there is their own gcc inserted just at the right time in order to
produce the binaries they want. A package is built by the packager and a signed
e-mail is sent to the signatories to sign it, because it's an update.

Given this is a new update, another build system, located elsewhere and not
publicly accessible, pulls in the package source and builds it. If that other
system wasn't broken into, it will produce a different binary for sure.
Immediate alarm bells for signatories.

Sure, this is a difficult thing to do right. It doesn't fix all intrusion issues
(nothing can). Takes a lot of effort etc. But it does provide at least some
checks and balances before packages are swallowed by users out there.

No offence, but right now we have a single point of failure that we already know
can be cracked. And that single point of failure is the single point of users'
trust. Not a very safe combo, IMHO.

Never mind, it was just an idea. Probably not even a good one. Back to the
drawing board... ;-)


More information about the fedora-devel-list mailing list