auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 9, 2006, at 10:21 PM, Andrea Arcangeli wrote:

> 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 I said, everyone (and every application) has slightly different  
desires ...

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

The issue for the rpmlib keyring is that "existence" and "trust" are  
not (yet) separated.

Trusted keys exist in the keyring, untrusted keys don't exist in the  
keyring.

Sure the trust metric in a pgp metric can/will be used when I get  
around to finishing what
I intended.

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

rpm does have a rudimentary sense of "session" called a transaction.

Saving an automagically fetched pubkey with a transaction is what is  
needed
to harden the concept.

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

Heh, I wrote tgpg to hand to gpg bigots. In fact, creating package  
sized blobs
outside of rpm in order to verify signatures is practically a non- 
starter, the size
of the plaintext is too large, and installers are already I/O bound  
without having
to create temporary files for signature verification. In addition,  
rpm verifies
signatures when importing/exporting the plaintext into its address  
space,
external verification of the plaintext is not as secure, as the  
plaintext can be
changed between verification and using.

Duplicating code was necessitated by licensing at the time of  
implementation.
rpm is LGPL, and gcrypt was not yet released. In fact I asked Werner  
whether
he would release gcrypt with LGPL, and received a lecture on how poor a
OSS developer I was because I worked for Red Hat. Go figger ...

There are other technical reasons for preferring beecrypt to gpg as  
well, its
really nicely written, and the native endian mpw_t permits 32bit and  
64bit
optimizations almost trivially.

But, by all means, rip the beecrypt signature handling out of rpm and  
use gpg if the
duplicated code offends. Have fun! ;-)

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

Default to "off" is being done to increase depsolver performance by  
morons who can't
run a benchmark.

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

Perhaps. All I can say is that there are far far easier ways to gain  
root
on N systems than messing with rpm packages.

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

Who said that a signature check on downloaded software isn't useful?  
Certainly
not me ...

73 de Jeff