[pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
allan at archlinux.org
Wed Sep 22 17:20:14 EDT 2010
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 :)
> 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:
The file extension is not consistent.
More information about the pacman-dev