As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11. There is already a Fedora 11 key that was used to sign beta and will be used to sign preview release, I would just revoke / delete the current ID which mentions testing and replace it with an ID of just "Fedora 11". fedora-release will be modified to handle this in the repo files as well.
If there are no strong reasonable objections this will happen early this week in time for the Preview release.
On Mon, Apr 20, 2009 at 6:17 PM, Jesse Keating jkeating@redhat.com wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11. There is already a Fedora 11 key that was used to sign beta and will be used to sign preview release, I would just revoke / delete the current ID which mentions testing and replace it with an ID of just "Fedora 11". fedora-release will be modified to handle this in the repo files as well.
If there are no strong reasonable objections this will happen early this week in time for the Preview release.
-- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
This is a very reasonable request. I definitely support this. +1
On Mon, Apr 20, 2009 at 7:17 PM, Jesse Keating jkeating@redhat.com wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11. There is already a Fedora 11 key that was used to sign beta and will be used to sign preview release, I would just revoke / delete the current ID which mentions testing and replace it with an ID of just "Fedora 11". fedora-release will be modified to handle this in the repo files as well.
If there are no strong reasonable objections this will happen early this week in time for the Preview release.
I'm good with this overall. In terms of updates signing, this should make things go more quickly as well assuming most people go the updates-testing -> updates route as packages should not need to be re-signed.
josh
On Monday 20 April 2009 06:17:21 pm Jesse Keating wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11. There is already a Fedora 11 key that was used to sign beta and will be used to sign preview release, I would just revoke / delete the current ID which mentions testing and replace it with an ID of just "Fedora 11". fedora-release will be modified to handle this in the repo files as well.
If there are no strong reasonable objections this will happen early this week in time for the Preview release.
sounds sane to me.
Dennis
Jesse Keating wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11.
Would it make sense from a security and release standpoint to still have two keys but to divide their use differently?
Key 1 is for beta/preview/release. Key 2 is for updates-testing/updates.
It seems like this would prevent most of the churn surrounding resigning since the resigning happens between packages from (beta => preview => release) and (updates-testing => updates) rather than (release => updates).
It would also mean that we could create a revocation certificate for Key 1 and then delete the private key after beta/preview/release. That would limit the time a malicious party could compromise the key used to sign rpms on media and in the release tree which seems like it would give us a better chance of having a known good base should we ever be faced with distrusting packages that made it into our repository.
Security is hard, though, so maybe someone can point out an error in my thinking :-)
-Toshio
On Mon, 2009-04-20 at 17:15 -0700, Toshio Kuratomi wrote:
Would it make sense from a security and release standpoint to still have two keys but to divide their use differently?
Key 1 is for beta/preview/release. Key 2 is for updates-testing/updates.
It seems like this would prevent most of the churn surrounding resigning since the resigning happens between packages from (beta => preview => release) and (updates-testing => updates) rather than (release => updates).
It would also mean that we could create a revocation certificate for Key 1 and then delete the private key after beta/preview/release. That would limit the time a malicious party could compromise the key used to sign rpms on media and in the release tree which seems like it would give us a better chance of having a known good base should we ever be faced with distrusting packages that made it into our repository.
Security is hard, though, so maybe someone can point out an error in my thinking :-)
RPM et al doesn't yet understand revocation certs, so that isn't going to help you much there. Other than that, since we'll be using new keys each release, I'm not even sure how much added value there would be in using two different keys.
Jesse Keating wrote:
On Mon, 2009-04-20 at 17:15 -0700, Toshio Kuratomi wrote:
Would it make sense from a security and release standpoint to still have two keys but to divide their use differently?
Key 1 is for beta/preview/release. Key 2 is for updates-testing/updates.
It seems like this would prevent most of the churn surrounding resigning since the resigning happens between packages from (beta => preview => release) and (updates-testing => updates) rather than (release => updates).
It would also mean that we could create a revocation certificate for Key 1 and then delete the private key after beta/preview/release. That would limit the time a malicious party could compromise the key used to sign rpms on media and in the release tree which seems like it would give us a better chance of having a known good base should we ever be faced with distrusting packages that made it into our repository.
Security is hard, though, so maybe someone can point out an error in my thinking :-)
RPM et al doesn't yet understand revocation certs, so that isn't going to help you much there.
Yeah, the revocation cert is so we can revoke it from any key servers. Nothing rpm related.
Other than that, since we'll be using new keys
each release, I'm not even sure how much added value there would be in using two different keys.
The added value is that once the release was cut, the key for the release would no longer be able to be stolen. So that cuts the window of vulnerability. But it only cuts the window a maximum of 13 months:
* Anytime before the release, the key could be stolen in either scenario. A key stolen in this way could be used to compromise the initial release after the release is cut
(1) With a single key, from release to 13 months out, the key could be stolen and potentially be used to inject bad packages into either the release or updates tree.
(2) With two keys, from release to 13 months out, the key to the updates repo could be stolen and used to inject bad packages into the updates repo only. The release repo would be safe.
Related thoughts:
For us to trust the release repo and only rekey the updates repo, we'd need to know the time that a key could have been stolen. If we couldn't determine that, we'd want to rekey both repos just to be safe.
The release repo is easier to verify (at least in part) than the updates repo because we generally have media that we can compare against for at least part of the package set.
-Toshio
On Tue, Apr 21, 2009 at 1:17 AM, Jesse Keating jkeating@redhat.com wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11. There is already a Fedora 11 key that was used to sign beta and will be used to sign preview release, I would just revoke / delete the current ID which mentions testing and replace it with an ID of just "Fedora 11". fedora-release will be modified to handle this in the repo files as well.
If there are no strong reasonable objections this will happen early this week in time for the Preview release.
Sounds like a good thing to do.
Just one other thing i notice here. Look at what you've done here. You seggest something and are going to implement it unless you get some feedback that lets you think. That on it's own is no problem for me.
The problem i see is that when anyone wants to request anything to be done in fedora they have to: - Write a detailed page on the wiki - Make a bugzille feature request - wait some time till it's reviewed (can be days, weeks or even months if ever) - let it be approved by fesco
and what else did i forget. I have to mention with that that it's just how i see new stuff getting in (or rejected). No first hand experience here but only how i witness it.
So now i'm wondering.. how come that you can get something in within a mather of hours and without explaining a lot or having to fill in a wiki proposal page? shouldn't you (specially you because your a redhat employee and should be an example for the rest) go through the same lenghty path as all other people have to do when they want to change anything at all in fedora? Somehow what you did seems a bit unfair to everyone making lengty proposals and letting them pass through all the required steps.
Just my observation here.
Mark wrote:
Just one other thing i notice here. Look at what you've done here. You seggest something and are going to implement it unless you get some feedback that lets you think. That on it's own is no problem for me.
The problem i see is that when anyone wants to request anything to be done in fedora they have to:
- Write a detailed page on the wiki
- Make a bugzille feature request
- wait some time till it's reviewed (can be days, weeks or even months if ever)
- let it be approved by fesco
and what else did i forget. I have to mention with that that it's just how i see new stuff getting in (or rejected). No first hand experience here but only how i witness it.
So now i'm wondering.. how come that you can get something in within a mather of hours and without explaining a lot or having to fill in a wiki proposal page? shouldn't you (specially you because your a redhat employee and should be an example for the rest) go through the same lenghty path as all other people have to do when they want to change anything at all in fedora? Somehow what you did seems a bit unfair to everyone making lengty proposals and letting them pass through all the required steps.
Just my observation here.
Different things being done with different goals. The process you list seems to be a hybrid of Package Review and the Feature Process. Package Review has a bugzilla ticket in order to get the package looked at by more than one person and to check for known problems that have been written down in the Guidelines. The Feature Process requires a detailed wiki page so that the Feature can be reported to end users and the media.
Most infrastructure and rel-eng changes don't affect end-users in the same way as new Features or new packages. They affect the delivery of the software to the user but they don't affect the user's experience with the software once installed. So the need to document for the end-user what's going on is not the same. If changing to a single key changed the security ramifications to the user or changed how they interact with the software, then a Feature Request and FESCo review may have been warranted.
Similarly, other changes that do have a large impact on others (not just end-users but Fedora developers too), are run by FESCo for approval before being implemented. Things like the provenpackager acl changes are a good example of something initiated by Jesse that were discussed at length before being approved by FESCo and implemented.
-Toshio
On Mon, Apr 20, 2009 at 8:28 PM, Mark markg85@gmail.com wrote:
On Tue, Apr 21, 2009 at 1:17 AM, Jesse Keating jkeating@redhat.com wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11. There is already a Fedora 11 key that was used to sign beta and will be used to sign preview release, I would just revoke / delete the current ID which mentions testing and replace it with an ID of just "Fedora 11". fedora-release will be modified to handle this in the repo files as well.
If there are no strong reasonable objections this will happen early this week in time for the Preview release.
Sounds like a good thing to do.
Just one other thing i notice here. Look at what you've done here. You seggest something and are going to implement it unless you get some feedback that lets you think. That on it's own is no problem for me.
The problem i see is that when anyone wants to request anything to be done in fedora they have to:
- Write a detailed page on the wiki
- Make a bugzille feature request
- wait some time till it's reviewed (can be days, weeks or even months if
ever)
- let it be approved by fesco
and what else did i forget. I have to mention with that that it's just how i see new stuff getting in (or rejected). No first hand experience here but only how i witness it.
So now i'm wondering.. how come that you can get something in within a mather of hours and without explaining a lot
To be fair it's not just a couple of hours. The idea was first mooted on 2009-01-16
http://fedoraproject.org/wiki/FWN/Issue159#New_GPG_Signing_Keys_for_Each_Rel...
and did not seem to stimulate much in the way of objections.
On 04/21/09 01:17, Jesse Keating wrote:
As I mentioned in an earlier thread I was interested in reducing the number of gpg keys down to one per release. Currently we have two, one we sign development builds with during beta/preview and updates-testing, and then one we sign the released packages with and the stable updates with. Multiple keys per release creates a lot of churn, reduces the number of hardlinks we can maintain, and causes a lot of delay in getting package sets prepped for the different releases. As such I'm proposing that we reduce the keys down to one per release, used for all the scenarios listed, starting with Fedora 11.
What is the plan for rawhide?
Would be great if packages don't need to be (re-)signed for (test) releases. So I could ask jidgo to scan the local rawhide mirror for packages when composing a beta iso.
cheers, Gerd
On Tue, 2009-04-21 at 09:41 +0200, Gerd Hoffmann wrote:
What is the plan for rawhide?
Would be great if packages don't need to be (re-)signed for (test) releases. So I could ask jidgo to scan the local rawhide mirror for packages when composing a beta iso.
Maybe with F12 we can start auto-signing packages for rawhide with the next release's key. We're just getting a signing server deployed that will help us with manual signing, but it hasn't been made to automate yet.
-
Dennis Gilmore -
Gerd Hoffmann -
Jesse Keating -
Josh Boyer -
Mark -
Neal Gompa -
Oisin Feeley -
Toshio Kuratomi