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