auto importing rpm gpg public keys from keyserver

[Andrea Arcangeli]

On Fri, Jun 09, 2006 at 05:14:34AM -0400, Jeff Johnson wrote:
> Then don't automatically add the public key to an rpmdb. There's  
> nothing in
> typing
> 
>    rpm --import 0x12345678
> 
> that is automatic. Nor is there any implied trust (or loss of  

This is the whole point, I don't want to type it, I want it more
automated, but not too much (i.e. not completely automatic).

As of today when the rpm signature check is enabled in smart, the first
unkown key will abort the whole thing. Instead of an immediate quit with
error, I'd like a question of the kind:

	Signature from unknown key 0x12345678 "XX xx" x at x.x, what should I do?
	Fingerprint of the unknown key is xx:xx:xx...
	IMPORTANT: if this system is critical you should select options
	1 or 2 only if you personally know and trust the signer and you
	can verify the fingerprint manually. If unsure 3 is the only
	safe option to select.
	1) trust this key forever (in future sessions too) by adding to the rpmdb
	2) trust this key only for this session
	3) don't install the package

I want to answer this question instead of aborting, or instead of of
disabling the rpm signatures checking (i.e. the unsafe default).

> security) if rpmlib
> fetches a public key for a stronger test of package integrity than a  
> digest.

rpm has to do the checking. What I mean is that the "trust this key only
for this session" should be implemented outside rpm. rpm doesn't even
know what a session is, how could it ever be able to cope with this? GPG
will also cache the key locally and it will avoid unnecessary multiple
downloads on the keyservers if you use the option 2 frequently.

> If you don't think rpm is "the best way" to verify signatures, then,  
> by all means,
> disable the mechanism in rpm, and verify the package signatures  
> however you wish.
> The script /usr/lib/rpm/tgpg will get you (or smart) started on that  
> path.

tgpg is certainly a viable way. But leaving signature check in rpm
should be ok, it's just the other mangling and questions and session
semantics that IMHO don't belong to rpm. The fact somebody wrote tgpg
means that somebody thinks too much gpg mangling hardcoded into in rpm
isn't actually a good idea.  I mean, we've gpg for it, why should we
duplicate all that code inside rpm? The rpm signaure check is one thing
and it makes sense to have in rpm so it's self-contained in the binary,
but the import of the key and showing details, stopping asking me
questions, handling the answer, should be implemented in smart using
gpg, nothing to do with rpm IMHO.  To say it in another way: adding a
gpg depdency to smart sounds reasonable while it would be less
friendly to add a gpg dependency to rpm.

> "branding" of otherwise identical OSS than anything related to  
> security imho. But I digress ...

Well, I disagree with this statement, infact I also disagree with the
current default to off. Default to off makes life easier, just because
the feature I suggested above isn't implemented yet. Once my feature
will be in there will be no good reason to leave it to off, because
anyone will be able to manage the failures generated by rpm while using
unofficial channels (this is the whole point of the feature, so everyone
will be capable of taking advantage of rpm signature check, and it makes
life a bit easier to us too).

Without checking the rpm signatures anybody hacking a mirror site or
capable of getting in the middle of a tcp/ip connection will gain root
on N number of systems that update from there (the cracker doesn't even
need root on the ftp site, he only needs to alter the rpm data). Now if
you want to downgrade the security of your mission critical servers to
the security that a random mirror or ISP has, go ahead, I know I won't.

The fact we also use a lot of downloads in plain tar.bz2 without
signature check isn't a good argument to say that a rpm signature check
on the updates isn't valuable. 1) _Everybody_ runs the security updates
and polls for them at high frequency (>1 time per day) so an hole of
just a single day would already do a quite significant damage, while
very few actually download tarballs (this fact also makes the man in the
middle attack much harder to coordinate with tarballs since you can't
know what the user will download next, while security updates are
trivially predictable and trivial to alter). 2) the few ones that
download tarballs and recompile the software themself, often review the
diffs or part of the diffs, 3) often we download the tarball comes from
the main site and not from random mirrors (and for packages like the
kernel proper signatures exists, but then I don't expect anybody to
check them even if they download from a mirror ;), while security
updates basically only come from mirror sites. With signature check
enabled you can choose the faster mirror without worring of who is
administering it.

Now, I imagine there's also a number of users that probably doesn't care
about security in the first place, but clicking 1 once in a while will
work fine for that desktop userbase too, and this way they'll have a
chance to notice if they suddently start to get too many questions by too
many gpg keys ;).