[pacman-dev] [PATCH 1/5] pacman-key: keyring management tool

[Allan McRae]

On 23/09/10 03:14, Denis A. Altoé Falqueto wrote:
> On Thu, Sep 16, 2010 at 12:40 AM, Denis A. Altoé Falqueto
> <denisfalqueto at gmail.com>  wrote:
>> The script pacman-key will manage pacman's keyring. It imports, exports,
>> fetches from keyservers, helps in the process of trusting and updates
>> the trust database.
>>
>> Signed-off-by: Denis A. Altoé Falqueto<denisfalqueto at gmail.com>
>> ---
>
> Allan, I'm thinking in change some parts of this patch. I've seen you
> already applied to your git repository, so should I send the patch all
> again or should I send a "patch to the patch"?

Go with a patch to the patch.  I will rebase them together before it 
becomes time to pull it into master.

> I want to do two things:
>
> 1. the --add command should behave just like gpg, importing from stdin
> when there's no files specified. I'm struggling with parameter
> expansion, but I'll figure the correct way soon :)

Sounds fine.

> 2. the --reload option could be enhanced for the following scenario:
> Let's say an active developer leaves the project. So, his key must be
> put on the list of removed keys. But he has a personal repository that
> lots of people use and he signs his packages too. The current behavior
> would delete his key from the keyring and the user would need to
> manually add it every time the --reload option is run.
>
> We could have an option in pacman.conf that indicates which keys must
> be kept, even if in the list of removed keys. For example, an option
> called HoldKeys, in the same spirit of HoldPkg.
>
> Do you agree with the need and solution?

Just because a developer leaves, does not make his old packages unsafe. 
  So we really do not want to be rebuilding everything just to resign 
them.  I think that removing of a key needs to be handled more 
gracefully at a distribution level rather than immediately removing the key.

Saying that, the case of a developer leaving but still hosting a third 
party repo is interesting and probably needs some work around such as 
you have pointed out.  The pacman.conf options seems reasonable.  But 
how about having a system like:

addedkeys - key currently being used to sign packages
depricatedkeys - keys previously used to sign packages but still safe
removedkeys - keys that have been revoked.

I guess these are the sort of things that we will discover with some 
real world usage.


Also, I just noticed:
	local ADDED_KEYS="${PACMAN_SHARE_DIR}/addedkeys.gpg"
	local REMOVED_KEYS="${PACMAN_SHARE_DIR}/removedkeys"

The file extension is not consistent.

Allan