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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
