[arch-dev-public] Keyring package for real

[Pierre Schmitz]

Am 04.03.2012 05:38, schrieb Allan McRae:
> On 04/03/12 06:54, Pierre Schmitz wrote:
>> Hi,
>>
>> I have pushed an archlinux-keyring package into [testing] so we have
>> something real to talk about. I revised some of my initial ideas. The
>> package is compatible to pacman-key --populate; it seems gpg will also
>> just accept a keyring that is just a bunch of keys put into one file.
>>
>> The remaining issues is the install script of the actual package. Atm I
>> run "pacman-key --init" on install and "--populate" on upgrade. Is there
>> a scenario where running init might not be a good idea? It wont increase
>> security to let users do this manually; even worse: people might just
>> not do it then. So I am going with a "works out-of-the-box" experience
>> here.
> 
> There have been so many issues with people not generating enough entropy
> to generate the initial key with "pacman-key --init" that I am not so
> sure that this is a good idea.

I don't know. This is a problem on servers and VMs. But yes, I can also
just remove the --init part so people have to call it manually the first
time.

> Not that the revoke file is optional so you do not need to provide an
> empty one.

Probably a matter of taste, but I thought it might be good to be
explicit here and ship an empty file.

>> There are at least two problems with using pacman-key: It is extremely
>> verbose and it requires the keyring to be signed which will lead to a
>> bootstrapping problem. I started a thread about this on pacman-dev; so
>> if you have ideas why this signature check might not be useless let me
>> know there.
> 
> I will discuss pacman-key in the other thread.   But we still have a
> bootstrap issues here...   What key is the package signed by?  Users
> will need to verify that key.  I think this is the only case where a
> package should be signed by one (or more) of the master keys.
> 
> I am finding it difficult to see how turning on signing in a current
> system can be done both automatically and securely  (with a new install,
> setting up the keyring can be automatically done during install under
> the assumption that the user verified the install media...). Telling
> users to install a package that sets up their keyring without verifying
> the signature of the package first seems like a failure at step one.

I thought about this and came to the same conclusion as you at first.
One problem is that you simply cannot switch from an untrusted system to
a trusted one. If your system is alreaady compromized you can verify as
much as you like; the only way is to reinstall from scratch. So security
wise it does note make sense to treat that keyring package any different
than the ones you already have installed. If we make this step
artificially hard most people will just disable signature checks and
that is most likely not what we wanted.

So my suggestion is to make it reasonable easy to install the keyring
package but most important document how it works and what the security
issues are. And yes, we should also include some brief steps to verify
the signature of the keyring package itself for those who care about
that. We can also describe how to isntall and verify the master keys
manually.

Using the master keys to sign the keyring package is probably not a
good idea. Technically it is not needed as pacman will accept it if it's
just signed by one of the or by a packager key. It just complicates our
maintenance a lot.

Summing up: I think we should make it as easy as possible for users to
setup their keyring, but also be very transparent about what is going on
and how to optionally verify each step manually. A good measure to
decide if a certain step in the process is reasonable to increase
security or just annoying to the user is to ask yourself if a malicious
package would have to do it as well.

Greetings,

Pierre

-- 
Pierre Schmitz, http://pierre-schmitz.com