Kerrick Staley wrote:
I don't know the answers to most of the questions you have asked; I'm trying to figure them out myself.
I didn't mean to lay all of my questions on you -- i was just making a list of things that i'd like to see answered. I was actually just trying to make your job easier; sorry if it didn't come off that way.
I'm going to be documenting important features of the code and other things at https://wiki.archlinux.org/index.php/Package_signing ; please add anything interesting you find to that page.
Excellent. Thanks for taking this on.
Also, I think the KSK idea, which AFAIK Allan was going to go with, will make things too complicated (unless it's mostly implemented). Basically, I think each developer should have their own key, that each package will only need one signature, and that the repolists will also be signed by the last dev to edit them. Also, 4 or 5 devs will keep a CD or flash drive with revocation certs for everybody. This system is vulnerable to the compromise of a single developer key, and even more vulnerable if one of the aforementioned disks gets compromised, but it is much better than what we currently have, and the KSK system is basically just as vulnerable. Once we get this system off the ground, we can work out a more sophisticated protocol.
I agree that a KSK implementation is unnecessarily complex. The concept of a KSK was designed for a different purpose -- for authorizing arbitrary numbers of certs. Unless i'm misunderstanding some crucial part of the plan, Arch does not have arbitrary numbers of package builders to worry about. The revocation scheme is also unnecessarily complex. For that matter, revocation on PGP keyservers wasn't designed for this sort of application, and isn't secure enough for it. If we supply a keyring of valid signing keys, and can replace this keyring when necessary, then revocation certificates become irrelevant. In this scenario: - The top 3 key holders can still exist (i'll call them the Key Moguls). - The developer generates a key pair and sends his public key to the Key Moguls. - Key Moguls verify the key, and add it to the list of permissible keys. - The list of permissible keys are either retrieved separately by pacman or retrieved as a Special Package. - The list or Special Package (LoSP) is signed with a key from a Key Mogul (or two). - If it passes verification, the LoSP becomes (or already is) a keyring, and _replaces_ the previous keyring. - The Key Moguls' keys are in a separate keyring. This keyring can be similarly replaced if necessary. - If the LoSP has been updated, then users will see a notice, just like when pacman has been updated, suggesting that they update the LoSP before continuing. Or, it can be automatically updated, perhaps with a command-line option for no-auto-update. The potential security concern that i see with this scenario is if an attacker compromises both a package signing key (dev key) and a mirror. In this case, he can keep the new version of the LoSP from being pushed out, and may continue using the compromised key. Unfortunately, having the devs sign the repository doesn't help this situation, since if both a dev key and a mirror are compromised, then the dev key could be used to sign an altered repository, and once again, the new LoSP could be omitted. However, if an additional "dev key" can be used to automatically sign the repository _in addition_ to the developer himself, then both keys would have to be compromised simultaneously for an attack to become feasible. I'm not familiar enough with the Arch package distribution+mirror system to comment on whether this is a reasonable thing to implement. If AUR submissions are ever to be signed (this isn't handled by pacman anyway), _they_ might require a KSK. But AUR submissions are so iffy to begin with that users should be scrutinizing them before (compiling or) installing anyway. ari