[Yum-devel] GPG key importing

Menno Smits menno-yum at freshfoo.com
Tue Dec 14 12:26:49 UTC 2004


seth vidal wrote:
> On Mon, 2004-12-13 at 23:39 +1000, Menno Smits wrote:
>>The one problem with this is that it may lead to keys being imported 
>>multiple times (eg. if the gpgkey option is pointing to the wrong key). 
>>RPM does nothing to prevent this.
> 
> But it also doesn't really care if they do get imported more than once.
> However, I agree with you for cleanliness it should be imported only
> once.

Yep, not vital but would be nice to mess up peoples RPM databases too much.

>>The obvious way to avoid duplicate imports is to check the key ID of the 
>>downloaded key before attempting an import. It's easy to check if a 
>>given key ID is already installed. The hard part is parsing out key ID 
>>of the downloaded key. I could either implement some of RFC2440 to 
>>extract the key ID (could be tricky) or use GPG to do it (adds a 
>>dependency for yum on the GPG binary).
>>
>>Does anyone know of another way to handle this?
> 
> 
> not really, unfortunately.

I was thinking about how to write a rfc2440 parser when I found the 
pgpmsg module which does exactly what is required.

http://www.python.org/pypi?:action=display&name=pgpmsg&version=1.0

It parses the ASCII armoured key files nicely to easy to use Python 
objects. I can convert its output to the version and release fields that 
RPM generates (see below) and it gave correct results for all the 
fedora-release keys and the freshrpms.net key.

pgpmsg is a single .py file and GPL'd. Would there be any issue with 
distributing it with yum?

>>Also, does anyone know what the release field of an imported GPG key is? 
>>The version field is the key ID but can't find a number that corresponds 
>>to the release field.
> 
> Check the importKey functions in the rpm sources. I know the release
> field is explained there I just can't remember what it is.

Thanks for the pointer. I eventually figured it out (most of the rpm PGP 
code is horrible and devoid of useful comments).

The release field is public key's creation timestamp in hex.

The version field is the least significant four bytes of the 
(big-endian) key ID.

> The other thing of importance is that rpm 4.4 is changing all this. It's
> doing some automatic-key-verification bits. 
> 
> So you will want to keep that in the back of your mind. My interest in
> what you're suggesting for yum is for systems running rpm 4.2, 4.3 etc
> for 'semiautomatic' importing of gpg keys.

Ok cool, any pointers on how rpm 4.4 will do this?

> A couple of things to think about:
> 
> - what to do when sys.stdin is not a tty
> - what to do when yum is invoked -y or assumeyes is set in the config
> file

In both of these situations yum could do 3 things if a key is missing:
1) Just install the required key without asking.
2) Refuse to install the key, report an error and abort.
3) Do (1) or (2) depending on option in yum.conf.

I guess if users are worried about keys being installed automatically 
then they could just not have the gpgkey option set. Then yum will abort 
anyway if gpgcheck is on and a required key is missing.

What would you prefer?

Menno

Scanned by the NetBox from NetBox Blue
(http://netboxblue.com/)




More information about the Yum-devel mailing list