What would folks think of adding a [gpgkeys] section to the .treeinfo file? This could provide a general mechanism for anaconda to determine which keys to install by default (reference https://bugzilla.redhat.com/show_bug.cgi?id=253897). It could also be used by down-stream utilities (e.g. a yum plugin) for keeping clients up-to-date with gpgkey changes to the base distribution (not terribly common in rhel and fedora distribution, but moreso in custom spins).
Comments?
On Wed, 2011-03-30 at 20:07 -0700, Kay Williams wrote:
What would folks think of adding a [gpgkeys] section to the .treeinfo file? This could provide a general mechanism for anaconda to determine which keys to install by default (reference https://bugzilla.redhat.com/show_bug.cgi?id=253897). It could also be used by down-stream utilities (e.g. a yum plugin) for keeping clients up-to-date with gpgkey changes to the base distribution (not terribly common in rhel and fedora distribution, but moreso in custom spins).
Comments?
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.
-- Dennis
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?'
- Chris
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@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
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.
The idea here being that yum would just magically pick up all the keys and anaconda wouldn't have to know anything.
- Chris
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@redhat.com [mailto:anaconda-devel-list-bounces@redhat.com] 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@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.fedoraproject.org
-
Chris Lumens -
Dennis Gregorovic -
Kay Williams