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
-----Original Message----- From: Doug Chapman [mailto:doug.chapman@hp.com] Sent: Thursday, May 22, 2008 5:10 AM To: fedora-secondary-list@lists.fedoraproject.org;
tcallawa@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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-secondary-list
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
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
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
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
secondary@lists.fedoraproject.org
-
Doug Chapman -
seth vidal -
Tom Callaway -
Zhan, Yi