> Hmmm, something a bit self-contradictory in these two viewpoints. It's > trivial, but can't be encapsulated? not really - the steps are easy to import them - the trust metric/web of trust mechanisms are harder. > What's wrong with setting up an ssl-auth'd "key repository" to parallel > the yum repositories (to manage 1,2 on an institutional basis)? 3. is > <sigh> always a problem, but one that yum manages now by just ignoring > locally installed RPM's, which are the ones I'd list as "NA" unless the > local builder supplies a key in the local repository. Again - a trust issue - you have to know to trust who gave you the key and trust that their system hasn't been broken into. Go read the gnupg comments on the web of trust. It'll make more sense then. IF you really want to trust a gpg public key then get it from a big public key server and only get keys that have been signed by other people you know/trust as being authentic. > Maybe it isn't worth it because we already trust that YOU'VE done the > keychecking for everything in the repository, and we can't do any better > than run off and remain sync'd with the repository only anyway for those > RPM's that it supplies... hahaha. It's worthwhile if for some reason our central repo got cracked. We should be very watchful of evil. Very watchful. :-D -sv
