auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 10, 2006, at 12:21 PM, Pascal Bleser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrea Arcangeli wrote:
>> On Sat, Jun 10, 2006 at 12:57:48AM -0400, Jeff Johnson wrote:
> ...
>>> 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.
>
> I definitely don't want to interrupt nor get in the way of your
> interesting thread, but maybe we could also try to keep the discussion
> on focus regarding smart and find an approach that would enable
> importing keys on demand in smart and with the current features of  
> RPM.

> Other options, such as implementing better support for keyrings in RPM
> itself seem a bit off-shot to me
> - - RPM is already a very complex tool (and I had instant nosebleeding
> looking at the source code), and I think Jeff is a good maintainer,
> knowing what features to add or not
> - - adding features in RPM that would make it easier for smart (and
> others) to support that would take a lot of time to get into
> distributions and, hence, I'd say it would be of no help before  
> maybe 2
> or 3 years
>

Yep. Adoption of new release of rpm is taking 2+ years, so  
essentially nothing can ever be fixed in rpm anymore.

Meanwhile, I'm planning for June 2008 ;-)

> So, basically, what do we need in smart ?
> - - detecting packages that are signed with keys that are not in RPM's
> keyring:
>   * is it possible to know that beforehand ? from repository metadata,
> possibly ?
>   * can we only notice that when a package is actually being  
> installed ?
>  (= the RPM transaction being made/committed) - if so, how would smart
> best react to it ? how do we notice, parsing output or a return  
> code of
> an rpm-python function ?
>

Detection is certainly possible before installing, all the necessary  
API's exist within rpm-python.

There is also an exception thrown for NOKEY to which a user dialogue  
or GUI pop-up can be attached.

> - - implement a dialog in every interface (text, text/interactive  
> and gtk)
> that tells the user that the transaction contains packages that are
> either unsigned or signed with a key that's not trusted (i.e. not  
> in the
> RPM keyring)
>

The dialog kinda has to be at the application, not the rpmlib  
library, layer. The alternative,
having the library transparently (and sneakily) attempt fetching and  
verifying without
changing application code invariably "surprises" users, see the  
beginning of this thread.

> - - implement key fetching from keyservers
>
> What about embedding a URL (or the key itself) in .channel files ?
> Maybe even add a signature on channel files themselves...
>

hkp is really easy, adding other locations for retrieving pubkeys  
usually leads
to a different, overly engineered poorly designed, complexity failure.

But by all means, do what looks useful, rpmlib certainly doesn't care  
what
applications do, or how keys are added to the rpmdb keyring.

> Novell added signed repositories support in SUSE Linux 10.1 (for yast2
> and RPM-MD repositories):
> http://en.opensuse.org/Secure_Installation_Sources
>
> Implementing support for that would be interesting as well.
>

Certainly useful and interesting, but outside the scope of package  
signatures verification.

> ...
>>> Default to "off" is being done to increase depsolver performance by
>>> morons who can't run a benchmark.
>
> Jeff, do you have any idea/gross numbers on how signature checking
> affects performance ? (not very important, just asking out of  
> curiosity ;))
>

Run your own benchmark:

      rpm -qa --stats

Compare with

     rpm -qa --nodigests --nosignatures --stats

Last I checked on my 600Mhz Dell several years ago, the overhead was  
~10ms/signature,
not shabby or slow at all. But add up 10ms per header over hundreds  
and thousands of headers, and one
starts to see scaling performance problems.

>> 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).
>
> Nevertheless, I personally think signature verification should be  
> turned
> on by default, not off.
>

The problem is that applications like yum have chosen to disable  
signature/digest
checking on a per-application, rather than per-system, basis.

Which means that there are multiple conflicting incoherent package  
verification policies depending
on what application is being used, and the inevitable shoot-out  
between competing
depsolvers like yum, apt-rpm, smart, whatever are based on  
performance metrics
that are jiggered to appear faster by disabling digest/signature  
checking.

Isn't OSS grand?

>>> Perhaps. All I can say is that there are far far easier ways to gain
>>> root on N systems than messing with rpm packages.
> ...
>> 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.
>
> +1
>

Been on the todo list for years. Check back in June 2008 please ;-)

73 de Jeff