auto importing rpm gpg public keys from keyserver

[Pascal Bleser]

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

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 ?

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

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

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.

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

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

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

cheers
- --
  -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
  /\\ <pascal.bleser at skynet.be>       <guru at unixtech.be>
 _\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEivF5r3NMWliFcXcRAuiHAKCq29YdMFnESwxONIcdN3lS4Z+LtACfcAlc
e7WOE8acL5J9EwD08T1o1ZI=
=7Feb
-----END PGP SIGNATURE-----