auto importing rpm gpg public keys from keyserver

[Andrea Arcangeli]

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

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

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

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