auto importing rpm gpg public keys from keyserver

[Andrea Arcangeli]

On Sat, Jun 10, 2006 at 12:57:48AM -0400, Jeff Johnson wrote:
> As I said, everyone (and every application) has slightly different  
> desires ...

Sure.

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

Yep.

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

I'm not opposed to that, but I don't see much of a point to have
untrusted keys being known by rpm, when we have the same logic already
implemented and working in gpg.

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

Good point as long as smart really does a single rpm command (which
wasn't obvious to me when there are zero dependencies shared by the
packages) but how can rpm can popup a GUI dialog windows asking the
question anyway?  Interpreting rpm output (like smart is partly already
doing) isn't a very nice API protocol, it only complicates things a bit
and makes it fragile, I don't really see a big gain compared to using
gpg with a more well defined api.

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

Sure, it makes perfect sense to do the check in rpm, infact I never
proposed to change that. All I want is to track when rpm says "sorry no,
I don't know the key", and to take a very slow path from there to ask
the question to the user, the slow path will be so slow that most of the
time will be spent retreiving the key and waiting the user to notice it
has to answer 1/2/3, so performance isn't an issue in the slow path,
while it's clearly an issue in the first verification check (that one is
in the fast path and the fast path belongs to rpm).

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

I never suggested to remove anything from rpm, infact I think I said
that adding a gpg dependency to rpm wouldn't be nice which completely
agrees with current model, plus there's the performance issue you just
mentioned that I obviously agree with ;).

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

Hmm, disabling signature check because then rpm runs slower sounds
really not a good argument to me. I think the only reason it is off is
because my feature is missing and most people would be annoyed by rpm
failing while using smart with unofficial repos then. That one is a good
argument since some people may not care about security at all (like I
said at the end of the last email), or they know their mirror is
certainly more secure than their desktop, but even then we should try to
help them keep their system secure, if we can do that without causing
too much pain (and answering 1/2/3 isn't too much pain IMHO).

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

On N systems perhaps, but on my systems I doubt. This is just a matter
of probability, on my server systems there are zero suid, not even su
and cron have the suid/sgid bit set and none of the network daemons runs
as root (no ssh available either). Kernel is 2.6.16+ so the only way to
get root is either a rpm signature missing or a bug in the kernel (and
the most critical parts as far as my exposure to the kernel is concerned
are the firewall code and seccomp, but then exploiting the kernel isn't
always easy if you've no login and you can't run all syscalls, it's more
likely any bug will generate a DoS than to gain root).

But let's not go offtopic. You may be right that it has never happened
that a rpm mirror was maliciously altered, but frankly I doubt all
mirrors are as secure as my system (the pain I got through to remove all
suids and not having ssh open is significant), so I keep signatures on
(just in case ;).

Before somebody asks ;) note that for the servers, I only install from
the official repos, so effectively for the above servers switching the
default to on like I already did with 'smart config --set', would be
more than enough already (I would never get 1/2/3 questions and if I get
a failure it means somebody is trying to exploit my systems), but I like
to have the feature for the desktop too where I may be using unofficial
but semi-trusted repos from popular sources without totally losing
control of the signers (so if I get screwed I want to be sure to be in
good company ;).

Overall if you really willing to add the untrusted-key management to
rpm, instead of leaving rpm doing only the fast-path signature check
against its own trusted-db, I won't object further but, it just seems
unnecessary to me, especially for the GUI. 

Thanks.