Not sure I am following the comment "see what got dropped into /etc/pki during tree composition". Perhaps you mean "after package installation is complete"? An advantage of looking up keys from a source outside of the packages themselves is that keys can be installed/updated prior to package install, allowing packages to be checked during install. I guess what I'm looking for is a general solution for identifying "trusted keys" for "trusted repositories" that can be installed automatically by anaconda/yum without prompting users. This should be extensible so that system administrators can specify their own keys and change them over time, and installed systems can respond to the changes. Originally I was imagining .treeinfo could be the mechanism for identifying trusted keys for a trusted repository (the install repository). Perhaps this is better handled on a per repository basis, however, in which case perhaps the discussion should be around listing trusted gpgkeys in the repomd file? >From a security perspective, this approach has an advantage in that moves trust up a level, removing dialog boxes (do you want to add this key?) that users get into the habit of affirming by rote because they lack context to evaluate. If I trust a repository (let's say because it's provided over ssl using a trusted certificate), I also trust it's keys. Thoughts? -----Original Message----- From: anaconda-devel-list-bounces@xxxxxxxxxx [mailto:anaconda-devel-list-bounces@xxxxxxxxxx] On Behalf Of Dennis Gregorovic Sent: Thursday, March 31, 2011 8:40 AM To: Discussion of Development and Customization of the Red Hat Linux Installer Subject: Re: Add gpgkeys section to .treeinfo? On Thu, 2011-03-31 at 11:19 -0400, Chris Lumens wrote: > > Adding a [gpgkeys] section to .treeinfo is interesting. As you point > > out, it could be used by anaconda to install the keys during > > installation. However, I don't know that anaconda itself should be > > responsible for adding the section to .treeinfo. That belongs somewhere > > in pungi. > > Well, lorax would be responsible now - that's where the logic of > scripts/maketreeinfo.py has gone. > > But, why would anaconda need to look up which keys to import from the > .treeinfo? Wouldn't we just want to see what got dropped into /etc/pki > during tree composition?' To be honest, I haven't given it much thought. However, it feels like explicitly listing the keys is safer than doing a glob on a directory. > > - Chris > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
