On Tuesday, October 29, 2002, at 11:02 AM, Ben Reser wrote:
This takes a little more careful thought. Putting GPG keys up without any kind of verification of the source can cause problems. For instance, suppose that PLF has a GPG key and we provide it in a package. Because it's on the keyring, urpmi will happily not complain if a PLF key is found in updates. What happens if PLF goes rogue, hacks into a mirror, and starts replacing updates packages with trojans that are signed with the PLF key? urpmi will install them without complaint. Now, I'm not saying the PLF folks are going to do this... =) This could easily be someone stealing their private key and doing it.How about putting your signing keys into a package that adds them to root's pubring?However this does bring up an interesting idea. Having urpmi/rpmdrake know where to find the GPG keys for various sources. I would propose that a file name is made as a standard for the key for a source that is placed in the same path as the hdlist/synthesis file. That file would contain a name or names of packages that contained the sites GPG keys.
But you should see my point.
I don't like this. The user should have to make some sort of effort to install these keys manually, or they should be in a MandrakeSoft-signed package. For instance, an rpm-gpg-keys package, provided by MandrakeSoft, signed by MandrakeSoft's key.On the first install from that source urpmi/rpmdrake would prompt the user if they wished to install this key. The file would then be downloaded and installed prior to any other package installations.
In the future if the key would need upgrading the version/release couldYup, my thought exactly. Also, urpmi would need to change before I'd advocate something like this. With apt you can define a key fingerprint that matches a particular source. For instance, one could map the security key fp to the updates source; the mdksoft official key to the cooker or distrib (ie. cd's) source. The logical step is then to map the rpmhelp key to rpmhelp.net, plf's key to plf, etc.
be incremented causing urpmi/rpmdrake to update it. urpmi/rpmdrake
would store the package name(s) of the keys. So it would always cause
that package to be updated in a separate rpm call prior to updating the
rest of the packages.
To ensure the keys and there is a trust chain it's possible Mandrake
could sign the packages for these people. I don't think there are a lot
of sites using the urpmi system. But perhaps Mandrake signing the
packages would be a bad idea for trust and work load issues.
Until urpmi can do this (Francois?), we shouldn't entertain this idea. It opens up too many possibilities I'm not comfortable with. Having urpmi do this sort of checking would make it a lot safer and, as a result, a good idea. But it's not a good idea with urpmi as it is now.
This is actually something I've thought about for a while, but never brought up (dunno why). I'd like to see urpmi become more popular, and possibly adopted by other distros. A fellow locally tried to get urpmi working on a RH system... he couldn't rebuild it, but he could install it from what I understood, his preliminary tests worked (ie. he could "urpmi djbdns-localcache" and it worked, even if the packages themselves wouldn't work as they're highly mdk-specific).
Francois? What do you think about adding this feature? It could be something configurable in a /etc/urpmi/sigs.conf or something; if there is no entry for a mirror, then do the normal thing, but if the entry exists, not only check that the gpg sig is ok, but make sure the fp matches the appropriate source.
Just a thought. What do you guys think?
-- MandrakeSoft Security; http://www.mandrakesecure.net/ "lynx - source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
