On 6 Mar 2003, seth vidal wrote:
> > I don't see it -- this complexifies a simple design --
>
> good word.
... the question is who is in charge -- you or the language.
I like to think that language serves me <grin>
> > 1. Why re-invent the wheel in yum for a key import task which
> > rpm already does?
>
> I think the general idea I've had is to discourage people from using rpm
> so they never learn of evil commands like --nodeps and --force
Good issue, but the solution you seek is not here in yum.
There is an infinite supply of indifference to sage advice,
and ignorance to boot.
> So if they do a lot of functions through yum then they stop thinking
> about it through other interfaces. It's sorta like how no one uses dpkg
> for installations.
ummm ... There is another way than dpkg? <grin>
> now all I need to find out is if I can specify only certain pubkeys to
> be used during checking.
>
> That'd be terribly handy.
I don't see the handiness of key scope restriction -- Why do
you think so? It sounds like another 'complexification' with
no clear mandate.
The discussion on key revocation is warming up over on the
fedora-devel list as well, where I have been pushing yum.
There is the 'paranoid' group, of which I am a member, and the
'we'll solve that later' group.
RPM has no clear mechanism for key revocation post-processing
-- assume a key is revoked; there is no mechanism for periodic
recheck by RPM that a signed package is still signed by a
trusted key; even if there was, there is not, and simply
cannot be a 'complete' "roll-back" mechanism to revert out
arbitrary content. People who think complete roll-backs are
or will _ever_ be always possible have not thought it through.
Further, there is no mechanisn for learning of a revocation.
RPM is not cronned -- rpm can be running standalone on a host
consciously isolated from ever attaining direct external
access to a PKI on the insecure internet or in an intranet.
I admin such hosts, and they update against private mirrors
which hold content, the availability of which I have expressly
approved. This isolation is functionally required with some
parts of HIPAA and Gramm-Leach-Bliley implementations; it is
required for effective change control and management.
- Russ Herrold
--
end
======================================+
.-- -... ---.. ... -.- -.-- |
Copyright (C) 2003 R P Herrold | Owl River Company
herrold@xxxxxxxxxxxx NIC: RPH5 (US) | "The World is Open to Linux (tm)"
My words are not deathless prose, | Open Source LINUX solutions ...
but they are mine. | info@xxxxxxxxxxxx -- Columbus, OH
gpg --keyserver pgp.mit.edu --recv-key 0x7BFB98B9
gpg --list-keys 2> /dev/null | grep 7BFB98B9
