[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Add gpgkeys section to .treeinfo?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]