Hi,
While playing around with package/database signing, I noticed that I could only validate my packages if I imported my key with pacman-key and then gave it "ultimate" trust. Setting "high" trust allows the signing to be verified but with an unknown trust level. So it seems to me that we always need (at least) one key with ultimate trust in our pacman keyring. I am still confirming my understanding of this on the gpg mailing list so feel free to correct me if I am completely wrong!
So, the procedure for someone to use a signed repo would be either:
1) Import the key for a signed repo (which may be used to sign other keys for that repo) and give it "ultimate" trust. While giving ultimate trust to a key that is not yours may be a bit strange, it is only ultimate trust as fas as the pacman keyring goes so may be acceptable...
2) Have your personal key in the pacman keyring with "ultimate" trust. Import the key for the signed repo and locally sign it with your key. If that key is a "master key" that signs other keys used in the signed repo, then we need to give it a trust level (probably full...).
I think both methods have their pros and cons. It should be up to the user to decide which they use.
The second method has the advantage that you have to explicitly give the key a trust level so importing a key for a repo does not allow that key to be used to install a package adding a bunch of new keys which have been signed by it. It has the disadvantage that you would have to import your secret key into pacman's keyring...
If people think the second method is reasonable, it would be good to add an option to pacman-key to allow signing (locally only) of keys.
Discuss! Allan
On Wed, Nov 24, 2010 at 3:10 AM, Allan McRae allan@archlinux.org wrote:
Hi,
While playing around with package/database signing, I noticed that I could only validate my packages if I imported my key with pacman-key and then gave it "ultimate" trust. Setting "high" trust allows the signing to be verified but with an unknown trust level. So it seems to me that we always need (at least) one key with ultimate trust in our pacman keyring. I am still confirming my understanding of this on the gpg mailing list so feel free to correct me if I am completely wrong!
I'm afraid you are right. In my tests I couldn't validate without at least one key with ultimate trust level. The documentation made me believe that it would not be needed, but the problem is that it only deals with the personal keyring, which has at least one private key. I also contacted the gpg list, but none useful answer came out.
A key with ultimate trust is treated just like a key pair. For a external keyring, it seems that at least one key must be ultimately trusted, be it for having an associated private key or by being trusted as so.
So, the procedure for someone to use a signed repo would be either:
- Import the key for a signed repo (which may be used to sign other keys
for that repo) and give it "ultimate" trust. While giving ultimate trust to a key that is not yours may be a bit strange, it is only ultimate trust as fas as the pacman keyring goes so may be acceptable...
- Have your personal key in the pacman keyring with "ultimate" trust.
Import the key for the signed repo and locally sign it with your key. If that key is a "master key" that signs other keys used in the signed repo, then we need to give it a trust level (probably full...).
I think both methods have their pros and cons. It should be up to the user to decide which they use.
The second method has the advantage that you have to explicitly give the key a trust level so importing a key for a repo does not allow that key to be used to install a package adding a bunch of new keys which have been signed by it. It has the disadvantage that you would have to import your secret key into pacman's keyring...
Well, I don't feel very comfortable with duplicating my private key in a external keyring just for the sake of signing other keys. The first method has the same consequences that the second.
In the schema that I though, there would be a set of keys that would be used just to sign other keys and some strategic packages. Each key of that set would be signed by the other keys and a user would have to import and trust at least one of them with ultimate level. Just after that the trust would propagate to other keys.
If people think the second method is reasonable, it would be good to add an option to pacman-key to allow signing (locally only) of keys.
In fact, it already has. It is the --trust option.
On 25/11/10 00:41, Denis A. Altoé Falqueto wrote:
On Wed, Nov 24, 2010 at 3:10 AM, Allan McRaeallan@archlinux.org wrote:
Hi,
While playing around with package/database signing, I noticed that I could only validate my packages if I imported my key with pacman-key and then gave it "ultimate" trust. Setting "high" trust allows the signing to be verified but with an unknown trust level. So it seems to me that we always need (at least) one key with ultimate trust in our pacman keyring. I am still confirming my understanding of this on the gpg mailing list so feel free to correct me if I am completely wrong!
I'm afraid you are right. In my tests I couldn't validate without at least one key with ultimate trust level. The documentation made me believe that it would not be needed, but the problem is that it only deals with the personal keyring, which has at least one private key. I also contacted the gpg list, but none useful answer came out.
A key with ultimate trust is treated just like a key pair. For a external keyring, it seems that at least one key must be ultimately trusted, be it for having an associated private key or by being trusted as so.
The reply I got from the gpg list indicates that we are right here and at least one ultimately trusted key is needed. So that at least clears up one confusion...
So, the procedure for someone to use a signed repo would be either:
- Import the key for a signed repo (which may be used to sign other keys
for that repo) and give it "ultimate" trust. While giving ultimate trust to a key that is not yours may be a bit strange, it is only ultimate trust as fas as the pacman keyring goes so may be acceptable...
- Have your personal key in the pacman keyring with "ultimate" trust.
Import the key for the signed repo and locally sign it with your key. If that key is a "master key" that signs other keys used in the signed repo, then we need to give it a trust level (probably full...).
I think both methods have their pros and cons. It should be up to the user to decide which they use.
The second method has the advantage that you have to explicitly give the key a trust level so importing a key for a repo does not allow that key to be used to install a package adding a bunch of new keys which have been signed by it. It has the disadvantage that you would have to import your secret key into pacman's keyring...
Well, I don't feel very comfortable with duplicating my private key in a external keyring just for the sake of signing other keys. The first method has the same consequences that the second.
I agree that I would not import my private key into an external keyring. Especially not if I was an admin for a server that multiple people access... But I would create a key as the "master" key for that keyring only. And the methods do have slightly different consequences (see below).
In the schema that I though, there would be a set of keys that would be used just to sign other keys and some strategic packages. Each key of that set would be signed by the other keys and a user would have to import and trust at least one of them with ultimate level. Just after that the trust would propagate to other keys.
There is an important difference between (1) setting the repo master key(s) as ultimately trusted and (2) having an ultimately trusted key that signs the master key(s) for a repo.
I agree that in the case of a distribution with large numbers of developers, there is effectively no difference. You will always need to give a "master" key or three a lot of trust so you accept their signatures on all the developers keys. In this case there is little effective difference between the two methods.
However, if you are using an external repo maintained by one person, you probably do not want to give that persons key any rights to sign other keys. So I would not want to give that key ultimate trust. However, locally signing the key would allow me to accept the packages from that repo as validly signed.
If people think the second method is reasonable, it would be good to add an option to pacman-key to allow signing (locally only) of keys.
In fact, it already has. It is the --trust option.
Ah... of course (and the --adv option is always there...). Maybe we should rename the --trust option to --edit-key to keep in line with what GPG is really doing there and to make it clear you can set more than just trust. Also, it always seemed weird to me that I was setting --trust and then had to type "trust" again at the prompt to do it.
Allan
On Wed, Nov 24, 2010 at 1:58 PM, Allan McRae allan@archlinux.org wrote:
The reply I got from the gpg list indicates that we are right here and at least one ultimately trusted key is needed. So that at least clears up one confusion...
Good!
However, if you are using an external repo maintained by one person, you probably do not want to give that persons key any rights to sign other keys. So I would not want to give that key ultimate trust. However, locally signing the key would allow me to accept the packages from that repo as validly signed.
Agreed. A special key pair just for the purpose of trusting is very appropriate, specially with third party repositories. I'll update the wiki page with that advise.
If people think the second method is reasonable, it would be good to add an option to pacman-key to allow signing (locally only) of keys.
In fact, it already has. It is the --trust option.
Ah... of course (and the --adv option is always there...). Maybe we should rename the --trust option to --edit-key to keep in line with what GPG is really doing there and to make it clear you can set more than just trust. Also, it always seemed weird to me that I was setting --trust and then had to type "trust" again at the prompt to do it.
Yeah, I can change that. I really suck at naming things :)
On 25/11/10 02:31, Denis A. Altoé Falqueto wrote:
On Wed, Nov 24, 2010 at 1:58 PM, Allan McRaeallan@archlinux.org wrote:
However, if you are using an external repo maintained by one person, you probably do not want to give that persons key any rights to sign other keys. So I would not want to give that key ultimate trust. However, locally signing the key would allow me to accept the packages from that repo as validly signed.
Agreed. A special key pair just for the purpose of trusting is very appropriate, specially with third party repositories. I'll update the wiki page with that advise.
I would add it as an option to the wiki rather than a complete replace. Doing that is probably overkill for people who will just use the Arch repos, in which case setting one of the "Arch master" keys to ultimate trust would be fine.
If people think the second method is reasonable, it would be good to add an option to pacman-key to allow signing (locally only) of keys.
In fact, it already has. It is the --trust option.
Ah... of course (and the --adv option is always there...). Maybe we should rename the --trust option to --edit-key to keep in line with what GPG is really doing there and to make it clear you can set more than just trust. Also, it always seemed weird to me that I was setting --trust and then had to type "trust" again at the prompt to do it.
Yeah, I can change that. I really suck at naming things :)
Cool. That is the sort of thing you do not really notice until the script is given a really good use. Overall I am finding it very useful in managing my pacman keyring.
Allan
pacman-dev@lists.archlinux.org