[pacman-dev] (Locally) signing a key with pacman-key?

Allan McRae allan at archlinux.org
Wed Nov 24 16:58:10 CET 2010


On 25/11/10 00:41, Denis A. Altoé Falqueto wrote:
> On Wed, Nov 24, 2010 at 3:10 AM, Allan McRae<allan at 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:
>>
>> 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...
>
> 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





More information about the pacman-dev mailing list