On Tue, May 24, 2011 at 12:24:53PM +0200, Michael Calmer wrote: > > I re-worked the patches now. > > spacewalk-repo-sync uses now a fix directory with a GPG keyring to store > trusted keys.
Michael, I'm not quite happy about two things: - The interactiveness of the approach. Neither satellite-sync nor spacewalk-repo-sync were interactive in the past and I'm worried that making it interactive now could break expectations for people who run these from quartz or from cron jobs, when the scripts start to do some interactive manipulations. Also, this approach kinda assumes that you are a root on the Spacewalk server to hit that "y" to allow the key to be imported. But with spacewalk-repo-sync and the sync (and scheduled syncs), we finally were able to separate the root on the Spacewalk server from the content admin -- you can now define channel and repository *and schedule sync of the content* from the WebUI, without even knowing the root password. I wouldn't like us to lose this. - I don't quite understand why you use filesystem to store the pubring, why not put the keys to the database. That would make it much easier to manage them, for example to "ack" import of the key from the WebUI. When the distribution is being created, we could fetch the repomd.xml and the key right on the spot and let the user approve it right there, before the first sync. The biggest problem with your approach is the fact that repositories and channels are per-organization but the gpgdir in your patch is global. So again, it gets us back to the "you have to be root to manage things" approach. We already have a GPG and SSL Keys application which stores the keys in the rhnCryptoKey table, that even has the org_id column. Can't you just use this table to store the keys, instead of the gpgdir? Also, is it correct that there is a boolean in the rhnContentSource, instead of have a relation table which would list allowed and expected keys (in rhnCryptoKey) for each rhnContentSource? Essentially have per-rhnContentSource keyring. With the current boolean approach, I might have a key for some external repository that I don't trust much, mixed with key for my primary, most important content. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
