[packagekit] GNOME summit and more about GPG keys
rnorwood at redhat.com
Wed Oct 10 07:25:52 PDT 2007
Tim Lauridsen <tla at rasmil.dk> writes:
> On Tue, 2007-10-09 at 21:11 -0400, Robin Norwood wrote:
>> o Accepting a GPG signature should happen when you add a repository, not
>> when you try to install a package. yum repo config (not sure about
>> other backends) can include a URL to the GPG key...so, a yum plugin
>> could be created to check to see:
>> - foreach repo:
>> - Is GPG checking enabled?
>> - Is the GPG key installed?
>> - If not, then do the prompt user thing (the repo_signature_required
>> And if an unexpected GPG key occurs at some other time, probably just
>> error out...this way, the gpg check occurs early in the transaction,
>> instead of after PK goes away to think for awhile.
> The main problem here is you don't know the the key for repo, then
> setting up the repo, so you can't check if the key is imported into the
> rpm DB.
> It work the following way.
> * After some packages has been downloaded then first check if gpgcheck=1
> for the repo where the packages is downloaded from.
> * It that is the case then the signature for the package is checked,
> there is 3 possible results to the check.
> 1. The signature is ok.
> 2. The signature is not ok.
> 3. The signature cant be checked because there is no matching key in
> the rpm db, this will launch a question to import a key, if a gpgurl is
> defined, if the question is yes then the key will be imported into rpmdb
> and the package is rechecked.
> So this can't be done upfront, because we don't know what key we need
> before we have some packages to test.
All of the repos I see with a quick check have the gpgkey option set to
file:///etc/pki/rpm-gpg/FOO - isn't that enough? (And this is before
the gpg key is actually imported).
> The could be a case, there the upstream key for a repo is changed to a
> new one and need to imported to the rpm db, even if there have been
> imported a key for the repo before.
Hrm. Maybe. I guess if the private key were compromised, this could
happen. However, this would be an exceptional condition - maybe we
should leave the ability to accept a gpg key if a new one is found
during the transaction...but I still think a better place to do it is
the first time the repo is noticed.
> So there is no hard relation between repo & GPG keys, but there is a
> releation between a signed package in a repo and a key in the rpmdb.
Well, the relationship exists - each repo config has an option to point
to a single gpg file - it doesn't *have* to be that way, but good
practice would be for each repo to have no more than one GPG key.
> It could be solve if the rpms contains the repo definition, also
> imported the GPG keys into the rpm db when they was installed, but it is
> not easy to do, because 'rpm --import ' don't check if the keys exists
> already, it just imports it, so you can mess up you rpm db with
> duplicate keys.
Well, that could be worked around - and really, once you install an RPM
from someone, you're saying you trust them. There's no reason
repository owners couldn't do exactly this now.
As an aside, there should probably be a user friendly way to list and
remove the GPG keys the user has chosen to trust.
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
More information about the PackageKit