[pacman-dev] Finishing off the package signing issue -- call for contributors
allan at archlinux.org
Sat May 21 02:14:05 EDT 2011
On 21/05/11 15:53, ari edelkind wrote:
> 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
> 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.
All this is off-topic for this list as pacman will not care how packages
and repos are signed. It will just verify whether the package/repo can
be validated using the keychain it is provided.
More information about the pacman-dev