Hello,
I'd like to push the creation of our keyring package. This package will contain all gpg keys needed to verify our packages. First of all: if you disagree with everything I did: don't worry; I am fine if we end up with an entirely different solution but this should be a good start.
After talking to others I would sum up the design goals as: * clear and transparent process; for the maintainer and users * complete and verifiable history of changes * has to work without any internet connection * no magic, no binary blobs; keep it as simple as possible
As a result I created a git repo which is meant to store all packager and master keys: https://projects.archlinux.org/archlinux-keyring.git/ The advantage over putting these files directly into svn is that we could use a cleaner layout with subdirs, sign tags and verify the source. The result is a (signed) tarball which can be used in the actual package which would contain additional logic. The keyids are exported from archweb. I didn't distinguish between developers and trusted users as pacman itself does not know about this difference either. It also makes maintenance easier when people move between these groups or are active in both of them.
A package prototype can be found at https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/a... It is not in any repo yet but I hope to put something into [testing] after a brief discussion. All this package does is installing/updating all master and packager keys and add them to the pacman keyring.
Note that this does not set any trust level which is needed to actually verify packages. The user has to trust (lsign) each of the master keys to establish this. This is some kind of bootstrapping problem. Future versions of our installer should take care of and do this automatically during install.
To make live easier for our current users we could add a simple helper script which displays the master keys and lsigns them after confirmation. The best way to do this is to use gpg --import-ownertrust which takes a simple text file of the format "<keyid>:<trustlevel>". I wouldn't want to use a binary file here. It is important that users always know what is going on.
To sum things up: The keyring package would install all needed keys and contain a simple helper script to verify and trust the master keys. A news item would then describe how to use this helper but also show several ways to verify the authenticity of the master keys.
Greetings,
Pierre
[2012-02-19 17:18:51 +0100] Pierre Schmitz:
As a result I created a git repo which is meant to store all packager and master keys: https://projects.archlinux.org/archlinux-keyring.git/ The advantage over putting these files directly into svn is that we could use a cleaner layout with subdirs, sign tags and verify the source. The result is a (signed) tarball which can be used in the actual package which would contain additional logic. The keyids are exported from archweb.
I do not understand the purpose of this tree. Actual key verification happens when a user lsigns certain keys of their keyring, why do it here? Our public key infrastructure can cope perfectly well with a keyring package shipping corrupted keys, so long as users do some verification before lsigning the master keys.
If you feel our public key infrastructure needs more security, it should be added down in the infrastructure itself rather than convenience layers such as the keyring package.
Since that tree duplicates information from archweb and data that I thought we agreed to let keyservers handle, I would consider much simpler and convenient to generate the list of packagers from archweb and retrieve the corresponding keys from a keyserver as we go in the build() function of the package. And there should be no need to manually verify anything but the master keys: if there is, that would be a flaw in GPG and/or the use pacman makes of it, not the keyring package.
Cheers.
Am 20.02.2012 00:05, schrieb Gaetan Bisson:
I do not understand the purpose of this tree. Actual key verification happens when a user lsigns certain keys of their keyring, why do it here? Our public key infrastructure can cope perfectly well with a keyring package shipping corrupted keys, so long as users do some verification before lsigning the master keys.
Sure the verification in the update script is technically not needed. This is more a QA check for the package maintainer. And I'd also think it'll be good practice to ensure the the package only contains valid and fully trusted keys.
If you feel our public key infrastructure needs more security, it should be added down in the infrastructure itself rather than convenience layers such as the keyring package.
Since that tree duplicates information from archweb and data that I thought we agreed to let keyservers handle, I would consider much simpler and convenient to generate the list of packagers from archweb and retrieve the corresponding keys from a keyserver as we go in the build() function of the package.
The keyids come from archweb (maybe we can have a simple export later). We also download missing keys from the keyservers. Imho it's nice to have a local copy independent from any third party services. But sure, some of this design decisions are a matter of taste and we could even change it as we go. Imho it's more important to concentrate things that really matter here.
[2012-02-20 00:38:33 +0100] Pierre Schmitz:
Imho it's more important to concentrate things that really matter here.
I certainly agree with your design goals and basic package workflow; in fact, Allan and I already posted isomorphic packages to this list and no critics were made. Hence my discussing your specific tree and package.
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 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.
Greetings,
Pierre
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.
Not that the revoke file is optional so you do not need to provide an empty one.
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.
We could just create a news entry/wiki page with instructions on setting up the keyring. something like:
pacman-key --init wget $(pacman -Sp archlinux-keyring){,.sig} pacman-key --revc-keys <keys> (key IDs need widely published) pacman-key --verify archlinux-keyring-2012*-1-any.pkg.tar.xz.sig pacman -U archlinux-keyring-2012*-1-any.pkg.tar.xz
Allan
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
Hi all,
with pacman 4.0.3 in [testing] and as all repos are now completely signed we should have everything we need to finalize the keyring package. The archlinux-keyring package in [testing] should update your pacman keyring or ask you to initialize it first. It will then ask you for each master key to confirm it's trust.
What is left to do? * Maybe have pacman depend on archlinux.keyring * Set "SigLevel = Required" for all our repos in our default pacman.conf * Write a news item which describes the steps how to setup your pacman keyring (entropy problem should be covered) and how to install our keyring package * Think about if we should advice to start with a new keyring for those who already had used "SigLevel = TrustedOnly" and therefor imported and trusted individual keys. E.g. what happens if we revoke just a key etc..
PS: If you like to test several scenarios you can simply move /etc/pacman.d/gnupg.
Greetings,
Pierre
arch-dev-public@lists.archlinux.org