Time to resurrect multi-key signatures in RPM?

[Bojan Smojver]

Nils Philippsen <nils <at> redhat.com> writes:

> builds between
> separate build systems (that have different profile data) will
> inevitably differ.

That is a problem, I admit.

> Second, it makes the update system more vulnerable to DOS attacks,
> insofar as it only takes an attacker to hack himself into one of the
> signatories to produce bad signatures on updates he wants to block (if
> they e.g. contain security fixes). The risk of this is at least
> proportionally higher with multiple targets to choose from (think RAID-0
> and what it does to the probability of errors in such a set of disks).

If a signatory is producing bad signatures, just use another one. It is trivial
to discard packages signed by bad keys. It is also trivial to ask another
signatory from the pool to check and sign instead.

For instance, if there are 10 signatories in the pool and one of them starts
signing with a bad key etc., this will affect some number of packages (not all)
for a little while, all of which can be resigned by any of the other 9
signatories to make it up to N (which can be say 3 or something like that). That
DOS would not really last very long. In RAID terminology, you have plenty of hot
spares in the RAID-5 array.

Ditto if someone's key get compromised. Just revoke and let others sign. You
still have many eyes going over it.

Compare that to breaking the password on Fedora private key now. Much sweeter
for the attacker, as everything becomes wide open. In RAID terminology, you
single drive just died.

> Third, unless a signatory runs his own build system to verify package
> builds (and disregarding my first point), his signature doesn't have
> much value as he has to rely on the checksum data provided by the
> package maintainer in his signed email -- which relies on the build
> system not being compromised to begin with.

That is also not true. If the signatory receives a signed e-mail from the
packager with checksums in it (i.e. rpm -qp --dump, as per sv), the signatory
can verify that against someone else's build system that is not publicly
writeable (e.g. Matt's at Dell). Not everyone would need to run their own.

And remember, the attacker would have to break the build system _and_ fake the
signed e-mail from the packager AT THE SAME TIME and then get signatories to
sign without any checking. Much less likely then just compromising the build
system (which is what they can do now).

It is better to check against something then not to check at all, IMHO.

You know, maybe this would be a good opportunity for some cross-distro
cooperation. They could build our stuff on their build farms, we build their
stuff on ours (not everything - just updates). Then attackers need to compromise
all in order to get just one scalp. Quite an effort.

> Then there's the additional burden on maintainers -- yet another
> bureaucratic hurdle.

Yeah, security is always like that - pain in the arse. I still remember some
devs in the office chmod-ing everything to 777 because "it's easier" :-)

--
Bojan