[resend] handling rpm signing for secondary arch packages

[Doug Chapman]

Sorry if you get this twice, the fedora-secondary-list was bouncing but
appears to be working now so sending again to be sure everyone gets
this.


I would like to start a discussion about devising a procedure for
handling rpm package signing for secondary arches.  When we released the
F9 beta for ia64 we did not sign the packages however I feel we should
take care of this for F9 final (or at least have a good reason for not
doing it).

We should probably have a unique key for each arch.  Generating a key
and signing the packages itself isn't a big deal (I assume, I need to
learn how to do this but I understand the concept).  The problem is
making sure it works cleanly on the users end.

Currently the public key for the primary arches is saved in the
file /etc/pki/rpm-gpg/RPM-GPG-KEY and is part of the fedora-release
package.  This is then hard coded into the yum configs.

So I have 3 rough ideas on how to handle this cleanly.

1: a special fedora-release package for each secondary arch that has the
appropriate keys (personally I don't like this idea but figured I would
mention it for discussion).

2: we move the keys from:
/etc/pki/rpm-gpg/RPM-GPG-KEY
to
/etc/pki/rpm-gpg/$basearch/RPM-GPG-KEY

of course this means replicating the keys for x86 and ppc (and the 64
bit variants) in multiple places (but I guess those could be symlinked)
still would be fairly clean.


3: we do something similar to #2 but instead of using $basearch in the
path we have a post install script for the fedora-release rpm which
copies the appropriate key into /etc/pki/rpm-gpg/RPM-GPG-KEY based on
the arch of the system.  The nice thing about this is it doesn't require
any changes to the primary arches.  The script would only copy files
over if on one of the secondary arches.



thoughts?  I would like to get this resolved before long since it is one
of the final issues we want to fix before shipping F9 for ia64.

- Doug

[Zhan, Yi]

>  -----Original Message-----
>  From: Doug Chapman [mailto:[e-mail]]
>  Sent: Thursday, May 22, 2008 5:10 AM
>  To: fedora-secondary-list(a)lists.fedoraproject.org; 
tcallawa(a)redhat.com;
>  Zhan, Yi
>  Subject: [resend] handling rpm signing for secondary arch packages
>  
>  Currently the public key for the primary arches is saved in the
>  file /etc/pki/rpm-gpg/RPM-GPG-KEY and is part of the fedora-release
>  package.  This is then hard coded into the yum configs.
>  
>  So I have 3 rough ideas on how to handle this cleanly.
>  
>  1: a special fedora-release package for each secondary arch that has 
the
>  appropriate keys (personally I don't like this idea but figured I
would
>  mention it for discussion).
>   
I agree this is the last choice. 

>  2: we move the keys from:
>  /etc/pki/rpm-gpg/RPM-GPG-KEY
>  to
>  /etc/pki/rpm-gpg/$basearch/RPM-GPG-KEY
>  
>  of course this means replicating the keys for x86 and ppc (and the 64
>  bit variants) in multiple places (but I guess those could be 
symlinked)
>  still would be fairly clean.
>  
>  
>  3: we do something similar to #2 but instead of using $basearch in the
>  path we have a post install script for the fedora-release rpm which
>  copies the appropriate key into /etc/pki/rpm-gpg/RPM-GPG-KEY based on
>  the arch of the system.  The nice thing about this is it doesn't 
require
>  any changes to the primary arches.  The script would only copy files
>  over if on one of the secondary arches.
>   
In my eyes #2 is the best choice for us to solve this issue. Is there
any possibility to get this done within a few days? We planed to have
about 2 weeks delay for f9 final and there are already 10 days until
today. So if time doesn't work we may have to take #3 for ia64's f9
final. 

For #3, it seems RPM-GPG-KEY can only take one public key? I did a
simple try and find out that if a file holds two gpg pub keys, only the
first one is recognized when "rpm --import". If this is the case, I'd
prefer to cp the appropriate key into
/etc/pki/rpm-gpg/RPM-GPG-KEY-$basearch and modify the
/etc/yum.repos.d/*. This looks more _ugly_ but also more clear, users
could easy to tell that we are using a different key from primary's.
Overwriting RPM-GPG-KEY is somewhat confusing even that we explicit
declare it in the release note since users would still feel surprising
some day, say several months after the release, when "find out" they are
using a different key via the same filename as primary arches'. 

Yi

[Doug Chapman]

Adding Seth to the CC list per Spot's recommendation.

Seth, what we are looking to do is find a clean way to handle secondary
arch packages (in this case ia64 but eventually sparc, s390, alpha and
arm as well) which are signed with a different key than the primary
arches.

What we want to do is add a new key for ia64 to the fedora-release
package and not break any existing stuff.  We would like to avoid a
special fedora-release package that is specific to each secondary arch.

Do you have any suggestions from a yum point of view as to what would
work best here?

thanks,

- Doug



On Wed, 2008-05-21 at 17:10 -0400, Doug Chapman wrote:
>  Sorry if you get this twice, the fedora-secondary-list was bouncing
> but
>  appears to be working now so sending again to be sure everyone gets
>  this.
>  
>  
>  I would like to start a discussion about devising a procedure for
>  handling rpm package signing for secondary arches.  When we released the
>  F9 beta for ia64 we did not sign the packages however I feel we should
>  take care of this for F9 final (or at least have a good reason for not
>  doing it).
>  
>  We should probably have a unique key for each arch.  Generating a key
>  and signing the packages itself isn't a big deal (I assume, I need to
>  learn how to do this but I understand the concept).  The problem is
>  making sure it works cleanly on the users end.
>  
>  Currently the public key for the primary arches is saved in the
>  file /etc/pki/rpm-gpg/RPM-GPG-KEY and is part of the fedora-release
>  package.  This is then hard coded into the yum configs.
>  
>  So I have 3 rough ideas on how to handle this cleanly.
>  
>  1: a special fedora-release package for each secondary arch that has the
>  appropriate keys (personally I don't like this idea but figured I would
>  mention it for discussion).
>  
>  2: we move the keys from:
>  /etc/pki/rpm-gpg/RPM-GPG-KEY
>  to
>  /etc/pki/rpm-gpg/$basearch/RPM-GPG-KEY
>  
>  of course this means replicating the keys for x86 and ppc (and the 64
>  bit variants) in multiple places (but I guess those could be symlinked)
>  still would be fairly clean.
>  
>  
>  3: we do something similar to #2 but instead of using $basearch in the
>  path we have a post install script for the fedora-release rpm which
>  copies the appropriate key into /etc/pki/rpm-gpg/RPM-GPG-KEY based on
>  the arch of the system.  The nice thing about this is it doesn't require
>  any changes to the primary arches.  The script would only copy files
>  over if on one of the secondary arches.
>  
>  
>  
>  thoughts?  I would like to get this resolved before long since it is one
>  of the final issues we want to fix before shipping F9 for ia64.
>  
>  - Doug
>  
>  
>  
>  
>  _______________________________________________
>  fedora-secondary-list mailing list
>  fedora-secondary-list(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/fedora-secondary-list

[Tom Callaway]

On Tue, 2008-05-27 at 15:15 -0400, Doug Chapman wrote:
>  Adding Seth to the CC list per Spot's recommendation.
>  
>  Seth, what we are looking to do is find a clean way to handle secondary
>  arch packages (in this case ia64 but eventually sparc, s390, alpha and
>  arm as well) which are signed with a different key than the primary
>  arches.
>  
>  What we want to do is add a new key for ia64 to the fedora-release
>  package and not break any existing stuff.  We would like to avoid a
>  special fedora-release package that is specific to each secondary arch.
>  
>  Do you have any suggestions from a yum point of view as to what would
>  work best here? 
It seems like just adding the additional keys as
RPM-GPG-KEY-fedora-$BASEARCH makes sense, then just append the new keys
to the key list in the repo config file.

~spot

[seth vidal]

On Tue, 2008-05-27 at 15:25 -0400, Tom "spot" Callaway wrote:
>  On Tue, 2008-05-27 at 15:15 -0400, Doug Chapman wrote:
>  > Adding Seth to the CC list per Spot's recommendation.
>  > 
>  > Seth, what we are looking to do is find a clean way to handle secondary
>  > arch packages (in this case ia64 but eventually sparc, s390, alpha and
>  > arm as well) which are signed with a different key than the primary
>  > arches.
>  > 
>  > What we want to do is add a new key for ia64 to the fedora-release
>  > package and not break any existing stuff.  We would like to avoid a
>  > special fedora-release package that is specific to each secondary arch.
>  > 
>  > Do you have any suggestions from a yum point of view as to what would
>  > work best here?
>  
>  It seems like just adding the additional keys as
>  RPM-GPG-KEY-fedora-$BASEARCH makes sense, then just append the new keys
>  to the key list in the repo config file. 
The only hang up there is the .repo file is config(noreplace) so your
changes wouldn't go out to existing users. If this is not a concern,
then yes, absolutely this is the simplest answer.

The other option is something I'd need to research a bit but I _think_
the yum gpg key handler will allow for multiple keys-per-file.

So we could, arguably add the arch-specific keys to the KEY files. I
need to test this but it looks like yum will import all the keys in the
file and the keys are not config(noreplace) or even config

-sv

[Doug Chapman]

On Tue, 2008-05-27 at 15:34 -0400, seth vidal wrote:
>  On Tue, 2008-05-27 at 15:25 -0400, Tom "spot" Callaway
> wrote:
>  > On Tue, 2008-05-27 at 15:15 -0400, Doug Chapman wrote:
>  > > Adding Seth to the CC list per Spot's recommendation.
>  > > 
>  > > Seth, what we are looking to do is find a clean way to handle secondary
>  > > arch packages (in this case ia64 but eventually sparc, s390, alpha and
>  > > arm as well) which are signed with a different key than the primary
>  > > arches.
>  > > 
>  > > What we want to do is add a new key for ia64 to the fedora-release
>  > > package and not break any existing stuff.  We would like to avoid a
>  > > special fedora-release package that is specific to each secondary arch.
>  > > 
>  > > Do you have any suggestions from a yum point of view as to what would
>  > > work best here?
>  > 
>  > It seems like just adding the additional keys as
>  > RPM-GPG-KEY-fedora-$BASEARCH makes sense, then just append the new keys
>  > to the key list in the repo config file.
>  
>  The only hang up there is the .repo file is config(noreplace) so your
>  changes wouldn't go out to existing users. If this is not a concern,
>  then yes, absolutely this is the simplest answer.
>  
>  The other option is something I'd need to research a bit but I _think_
>  the yum gpg key handler will allow for multiple keys-per-file.
>  
>  So we could, arguably add the arch-specific keys to the KEY files. I
>  need to test this but it looks like yum will import all the keys in the
>  file and the keys are not config(noreplace) or even config 
I like this idea.  To be sure I understand right, nstead of adding a new
file we would just cat all the keys together
into /etc/pki/rpm-gpg/RPM-GPG-KEY right?  Then when yum imports the keys
it just gets them all?

I will test this out once I have packages signed with the new
fedora-ia64 key.

thanks,

- Doug

[Doug Chapman]

On Tue, 2008-05-27 at 15:34 -0400, seth vidal wrote:
>  On Tue, 2008-05-27 at 15:25 -0400, Tom "spot" Callaway
> wrote:
>  > On Tue, 2008-05-27 at 15:15 -0400, Doug Chapman wrote:
>  > > Adding Seth to the CC list per Spot's recommendation.
>  > > 
>  > > Seth, what we are looking to do is find a clean way to handle secondary
>  > > arch packages (in this case ia64 but eventually sparc, s390, alpha and
>  > > arm as well) which are signed with a different key than the primary
>  > > arches.
>  > > 
>  > > What we want to do is add a new key for ia64 to the fedora-release
>  > > package and not break any existing stuff.  We would like to avoid a
>  > > special fedora-release package that is specific to each secondary arch.
>  > > 
>  > > Do you have any suggestions from a yum point of view as to what would
>  > > work best here?
>  > 
>  > It seems like just adding the additional keys as
>  > RPM-GPG-KEY-fedora-$BASEARCH makes sense, then just append the new keys
>  > to the key list in the repo config file.
>  
>  The only hang up there is the .repo file is config(noreplace) so your
>  changes wouldn't go out to existing users. If this is not a concern,
>  then yes, absolutely this is the simplest answer.
>  
>  The other option is something I'd need to research a bit but I _think_
>  the yum gpg key handler will allow for multiple keys-per-file.
>  
>  So we could, arguably add the arch-specific keys to the KEY files. I
>  need to test this but it looks like yum will import all the keys in the
>  file and the keys are not config(noreplace) or even config 
I appended my ia64 public key to RPM-GPG-KEY but yum only imports the
first key in the file.  So it sounds like the best option would be to
add the new key as RPM-GPG-KEY-fedora-$BASEARCH.  I am not all that
concerned about the fact that the new config won't get installed on
existing systems.  We can document this so people can do a workaround on
previously installed ia64 systems.  The majority of the installs will
probably be fresh anyway.

- Doug