auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 10, 2006, at 9:29 AM, Andrea Arcangeli wrote:

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

My comment was intended sardonically, as rpm's signature mode is  
extremely poorly designed,
a onepass signature on *.rpm would have kept rpm in package  
management and out of crypto
forevermore.

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

We agree the dialog has to be done by an a application GUI, no way do  
I wish
rpm in the GUI business with dependencies on xorg. (shudder)

However, cert acceptance for https:// transport with neon is going to  
be an annoying callback to implement
in a batch oriented, no tty, installer like rpm (and rpmlib).

(newtopic)

Does it make any sense at all to attempt to use the linux kernel's  
keyring as rpm's keyring? The coding
does not look hard, certainly easier than Berkeley DB, and using an  
external common subsystem functionality
can only help expedite better implementations in applications.

73 de Jeff