auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 15, 2006, at 4:43 PM, Andrea Arcangeli wrote:

> On Thu, Jun 15, 2006 at 04:18:40PM -0400, Jeff Johnson wrote:
>> rpm itself uses only the fingerprint everywhere except the string you
>> just extracted.
>
> Well it's still unclear to me, if the thing is secure or not, or if it
> can be secure at all.
>
> The string I extracted doesn't need fingerprint, so that's not a
> problem. If there's a problem it can only be in rpm --import.
>
> All I need to know if pgpImportPubkey actually does more than adding a
> trusted "keyid" to the rpmdb. It must import _more_ then the keyid. If
> it does it's secure, otherwise it's not.
>
> If pgpImportPubkey only imports only the keyid, then it seems very
> flakey regardless of smart, you can't just compare keyids during the
> signature check.
>
> So I hope it does the right thing and that it's all working well ;)
>

pgpImportPubkey parses an armored pubkey, checking the CRC,
and wraps ithe blob in a header using pubkey packet parameters like
fingerprint and creation time.

The user id is never used as a retrieval key for the pubkey.
>> rpm is not trying to set policy, only provide a universally useful
>> mechanism. If applications like yum choose to clobber what the user
>> specifies in rpm  configuration, all I can do is shame developers
>> publically.
>
> How is it different to clobber or to ignore rpm at all? Current  
> smart is
> ignoring everything, it disables signature checking by default and yet
> you seem to be ok with current smart behaviour.
>

The issue is invariably
    What should the default be?
and there are valid points on both sides of performance vs. security.

It's not my place to argue either side.

Meanwhile, I'm very happy to see smart become opt-out rather than opt- 
in wrto
rpm pkg signature verification.

>> I know of no exploits through twisted rpm packaging in rpm-4.1 and
>> later.  In fact, I know of no current rpm exploits, but rpm-3.0.x and
>> rpm-4.0.x were *designed* to segfault when something was wrong,  
>> so ...
>> caveat emptor!
>
> ;)
>
>> Repeated requests for an audit of rpm, on vendor-sec, and at RH, over
>> the past 3 years have been met with deafening silence because of the
>> complexity of the  code paths. So much for the wonderful  
>> efficiency of
>> OSS development.
>
> If you can make it run under seccomp you'll be done with it, hope it's
> simpler than the audit ;), at least if you do it once you won't  
> have to
> worry to introduce exploitable bugs, while the audit is only valid  
> for a
> single snapshot.
>
> Pratically all decoders like mpeg/mp3/jpeg/divx/ogg are likely to be
> still exploitable, and seccomp is the only reasonable way to secure  
> them
> as well. gz/bz2 should do it too.
>
>> But its your security at risk, by all means, use chroot's and
>> "nobody" and whatever else you need to feel secure.
>
> The thing has to be by-default, otherwise nobody will do it. Again
> seccomp is the most friendly option of all, requires zero changes of
> uid, no chroot and it's an order of magnitude more secure.
>

Yep, almost every effective feature in rpm has been of the opt-out  
rather than the opt-in
variety.

>> And gpg and rpm are prolly equally prone to failure through exploits.
>> rpm installs -- because run as root -- are perhaps a more attractive
>> venue than gpg exploits.
>
> Agreed.
>
> About what I said that I didn't change anything in my patch in  
> terms of
> global policy I may have been wrong because I assumed that rpm had
> signatuers on by defeault unless you disabled them explicitly. I don't
> know how to turn them off by default in rpm after all, like it's  
> unclear
> how to turn them on with rpm-python. rpm._RPMVSF_NOSIGNATURES turns  
> them
> off, but what is the bitflag to turn them on? The lack of a bitflag
> opposite to rpm._RPMVSF_NOSIGNATURES is why I perhaps wrongly  
> assumed I
> had to create a new ts (safer anyway) and that they were on by  
> default.

rpm by default has an overly complex policy to choose what it  
verifies, basically:
     Prefer signatures over digests over sanity.
         Prefer header-only over header+payload.
              Prefer DSA over RSA. (not for any important reason, the  
RH key is/was DSA.)

Still, the choice is way too goosey-loosey for serious crypto.

73 de Jeff