On Tue, Aug 26, 2008 at 5:41 PM, Bojan Smojver bojan@rexursive.com wrote:
Seth Vidal <skvidal <at> fedoraproject.org> writes:
I think it will complicate things a lot for users to verify
Users wouldn't actually have to verify anything by hand. The idea was that yum does that for them. I don't see how that would be any more complicated then now.
Say there are 10 signatories in the pool. Yum would check that:
- the package is signed with the Fedora key
- the package is signed by at least N (say 2) other keys from the pool
- failing the above, it would not accept the package
N could even be configurable in yum for smooth transition from the single key scenario.
and it's not obvious how much we'll gain in terms of security.
It is similar to what a reporter does to confirm a story. One source, not so reliable. Two sources, more reliable. Many sources, most likely reliable.
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. 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... and you are going to have to come up with an additional income source to pay for the extra bureaucracy that is being added.
In terms of attacks, right now if somebody gets a hold of the password of the Fedora key, it's game over. Ditto if someone compromises the build system to start producing bad binaries.
With the multi-key, multi-build system, an attacker would need to get his hands on a lot of private key passwords, break multiple independent build systems etc.
Or just be in the right place somewhere. The build systems will not be completely independent or they would not be able to produce identical binaries..