[packagekit] GNOME summit and more about GPG keys

[Alexander Boström]

ons 2007-10-10 klockan 10:25 -0400 skrev Robin Norwood:

> 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). 

Ok, how about this... (I'm going to ignore non-yum now, because I don't
know much about the subject.) Let's for the sake of argument assume that
PK assumes that all .repo files are installed using RPM:s and that they
all use gpgkey=file://etc/pki/.... and include that key in the RPM. It
auto-accept all those and fails with an error on any other keys. Then it
would Just Work, for most repos.

Now, what would be the problems with that?

How do you verify the repo package? Ignore the problem for now, just
warn, like what happens now if you click on an RPM in the browser?

The user might install a repo manually or using an RPM which does not
contain a key in this way. Then installs or possibly even updates will
just fail. If the user doesn't know how to fix this, they're in trouble.
If no packages have been installed from that repo (would need to flip a
bit somewhere upon package installation to know that), then just ask the
user if it's ok to disable that repository. (User tried to add a third
party repo. It failed. Bad third party repo.)

A key pair might expire. You can push a new repo package with a new key
automatically, but you need to do it before the old key expires.
Otherwise, I assume you'll get an error saying the updated repo package
is signed with an expired key. Can we ask "Do it anyway?"?

A private key might be compromised. What to do then? Do you use the
private key one last time to push an updated repo package with a
replacement key? Do you make that package cleanse the RPM database of
the old key? How will that interact with a possible key blacklist
service? Well, if they key blacklist service also contains replacement
keys, that would work, except then you'd need to sign the new repo
package with the new key, which breaks for everyone who doesn't use the
blacklist service.

Perhaps this is the way to go, for now: Implement a blacklist, have a
scary hex code dialog for the few cases where it is needed and still
allow it to be fairly easy to install individual RPM:s without a valid
signature (the repo packages). And the above about disabling unused
broken repos and ok:ing expired keys.

It still wouldn't be secure, but neither would it hide any security
problems which are visible with current tools, so it's not a step
backwards.

/abo