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

[ari edelkind]

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