[Yum] gpg public keys
Robert G. Brown
rgb at phy.duke.edu
Fri Mar 7 13:17:57 UTC 2003
On 6 Mar 2003, seth vidal wrote:
> As some of you know gpg pkg signing, etc was changed in rpm 4.1 and
> Now keys are stored in the rpmdb, they're dealt with by beecrypt, they
> don't require gpg, etc etc.
> But, if you do an rpm -qa you'll see them in your list.
> I'm thinking about screening them out of the yum list output.
> Also thinking about making it so key imports could be handled via the
> yum command line. (not sure about this one, yet)
> I thought it might look cleaner if you don't have a bunch of gpg-pubkey
> things sitting in your yum list output.
Is there any way to fully encapsulate gpg keychecking? As in, have yum
always check gpg signatures and never tell you about it unless they fail
to match? Or is there something chicken-and-eggish about this...
Forgive me if it already does this.
As for output in yum list, a column with Y/N/NA in it for yes, gpg key
checks, no it fails, or not applicable, no key available might be a
decent option to have, as might a flag to tell it to list only packages
whose key is n,na, or just n. Those commands might play a useful role
in a security audit or a what's wrote with this damn system audit,
presuming of course that one can trust yum itself on a compromised
BTW, I sat and suffered through an hour of the aduva demo, and now fully
understand their product. I present a BRIEF summary for the benefit of
The product in question was a generalized package/revisioning management
scheme, not unlike yum in purpose and scope, designed to go into
topdown/centralized management linux environments, especially those that
I would call "a bloody mess".
The Aduva toolset, OnStage, works as follows:
a) Aduva maintains a centralized repository of RPMs that, AFAICT, is
the union of all the major distributions that use RPMs. My general
feeling was that they use RH as their central base, but are nevertheless
essentially distribution agnostic.
b) They install and run mixes of RPMs (ACROSS DISTRIBUTIONS) on a
heavy duty testbed LAN and build a massive dependency/compatibility
table. I believe that they rebuild RPMs "on demand" to resolve
dependency/compatibility problems for clients or to insert client RPMs
into their tables. They also have an automated kernel rebuilding tool
so that num-nums can (within reason) configure and build a custom kernel
off any particular base.
c) They provide their clients with a GUI tool to run on a management
console/server. This server autogenerates a cached archive (drawn from
the Aduva repository) of the packages and dependency tables required by
d) All client systems get a root-privileged daemon that can be
accessed (over ssl) from the server. This daemon is basically
equivalent to yum in very crude terms EXCEPT that it is run from the
central server instead of the client (topdown). It can run scripts,
gather information on all installed rpm's, get rpms, remove rpms,
generally groom a distribution according to the master console's
e) The master console provides client views and task views that are
something VERY MUCH LIKE what we were discussing as a GUI encapsulations
of yum, and of course were nearly feature identical with yum itself.
With a few clicks one could see what a client needed to update itself to
"current", accept or reject the proposed RPM's, initiate an update.
About what one would expect.
f) The master console could do a few other thingies -- clone a server
system (make a copy of its rpm list, then push it onto a client with
some degree of intelligence wrt /etc configuration, although I gathered
from my questions that this wasn't likely to be foolproof if it worked
at all). It did not provide encapsulated node/client dhcp/pxe or
floppy/kickstart or whateverthehellyoulike installation -- it did not
seem to be an installation tool. It did give one a GUI to control
cronly automation of updates and so forth.
The PRIMARY ADVANTAGE of the tool over what we have here at Duke already
is its ability to rationally manage bloody mess LANs, specifically ones
that have a RH 6.2 workstation next to a RH 7.3 workstation next to a
Mandrake system next to a SUSE system, with some SUSE RPMs installed on
the RH boxes and the need to use RPMs built on the Mandrake box on all
of the above. Their master database resolves dependencies and
functionalities much more broadly than any single distribution. This
is, as they openly admitted, their primary added value (along with the
GUI itself and the ability for one person to control revisioning and
updates throughout a topdown organization).
This could clearly be of value to organizations that a) have topdown,
centralized management; b) through incompetence (most likely) or because
of cost/difficulty porting or rebuilding mission critical applications,
have to run linux across versions and/or distributions.
Neither of these describes a typical University; quite the opposite. The
thought of running a root privileged daemon controllable from a single
campus master on every system on campus at Duke both makes me shudder
(the horror, the horror!) and laugh uncontrollably at the same time.
There would be mobs carrying torches and pitchforks at the very
suggestion, and I'd be right out front.
Then there is the Evil of mindless heterogeneity and distribution
crossover -- obviously nobody with GOOD management skills would ever do
something so stupid at an institutional level, although one can easily
see how things evolve into that state in a fairly chaotic, decentralized
environment or in one that is incompetently managed. Still, there DO
occur cases where somebody ends up with a system being "frozen" (at
least for a time) at some distribution because e.g. libc changes
dramatically and it would cost a great deal to port a critical app to
the new version, and there are always cases where a particular package
has been packaged for Mandrake but you want to run it under RH, and a
simple rpm --rebuild fails (leaving you screwing around with figuring
out what it needs and how, or whether, to provide it). Their tool is
likely to be be of SOME help in the incompetently managed, centralized
organizations (hiding and minimizing the impact of the bad management
practices) and is at least a different, possibly cheaper, pathway to
interoperability in a well-managed environment (where they would most
likely freeze a distribution on certain systems or slog through the rpm
Needless to say I pointed out to them that root-privileged execution
daemons, ssl-authenticated or not, were Dark Evil of the grimmest sort
and anathema in any decentralized environment (like Duke) where even the
great and noble Sethbot has neither privilege nor interest in HAVING
privilege (and the attendent responsibility) outside of his private
demesne, where the Duke Hospital has significant legal constraints on
who has root access to systems that might well freely use yum (as a
CLIENT SIDE tool), that the proper solution to mindless heterogeneity is
to eliminate it (where possible), and that all of these things place
fairly strong constraints on their likely market. Perhaps they'll sell
to undermanaged corporations (and provide decent value there). Perhaps
they'll find at least a small market at places like fermilab, where in
years past they've showed a bit of a penchant for trailing distributions
due to the porting problem for some of the MC apps (although I think
they've been better lately, right Seth?). They'll never sell here.
They did have a bit of difficulty with the open source issue -- I tried
pointing out that their real added value was the centralized server,
testing, and dependency resolution process, together with supported task
encapsulation tools and training for those local sysadmins, but alas,
they still think of themselves as selling software, and hence are doomed
to misery and despair as yum and other OS tools slice their market out
from under them for free. They did seem to listen, though, to my (one
and only) free consulting advice concerning topdown vs decentralized
management. If they want more advice, I think I'll make them pay for
it. OS solutions are worth contributing to for all the usual reasons;
closed source companies need to pay, pay, pay.
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
More information about the Yum