[pacman-dev] Finishing off the package signing issue -- call for contributors

[Allan McRae]

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
>> 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.
>

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.

Allan