FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 03-31-2011, 03:07 AM
"Kay Williams"
 
Default Add gpgkeys section to .treeinfo?

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?
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-31-2011, 02:56 PM
Dennis Gregorovic
 
Default Add gpgkeys section to .treeinfo?

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


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-31-2011, 03:19 PM
Chris Lumens
 
Default Add gpgkeys section to .treeinfo?

> 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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-31-2011, 03:39 PM
Dennis Gregorovic
 
Default 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
 
Old 03-31-2011, 03:53 PM
Chris Lumens
 
Default Add gpgkeys section to .treeinfo?

> > 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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-31-2011, 05:03 PM
"Kay Williams"
 
Default 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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 10:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org