I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remove... with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from-... And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?
Mirek
On 10/31/2017 09:52 AM, Miroslav Suchý wrote:
I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remove... with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from-... And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?
They indeed pile up after many upgrade cycles:
# rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l 64
On 10/31/2017 10:15 AM, Roberto Ragusa wrote:
On 10/31/2017 09:52 AM, Miroslav Suchý wrote:
I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remove... with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from-... And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?
They indeed pile up after many upgrade cycles:
# rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l 64
Do we issue revocations for old keys? If not, let's do that and extend dnf to honor those and clean up?
On Tue, 31 Oct 2017, David Cantrell wrote:
# rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l 64
Do we issue revocations for old keys? If not, let's do that and extend dnf to honor those and clean up?
What is the 'use case' for potentially preventing installation against a already know key of a existing, but older 'noarch' package; or one unpacking an older SRPM and NOT getting the scary NOKEY warning? The size of the keys is trivial, even though they do tend to accrete in a 'long running' instance
heck, I'll wager mostly those keys are never countersigned into a web of trust, and sent to the constellation of GnuPG key-servers in the first place
Going even further, and revoking the keys is 'fly-specking' overkill
I have no problem with removing keys not _used_ on a given host (such information being able to be compiled out of the RPM database)
-- Russ herrold
On 10/31/2017 11:32 AM, R P Herrold wrote:
On Tue, 31 Oct 2017, David Cantrell wrote:
# rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l 64
Do we issue revocations for old keys? If not, let's do that and extend dnf to honor those and clean up?
What is the 'use case' for potentially preventing installation against a already know key of a existing, but older 'noarch' package; or one unpacking an older SRPM and NOT getting the scary NOKEY warning? The size of the keys is trivial, even though they do tend to accrete in a 'long running' instance
heck, I'll wager mostly those keys are never countersigned into a web of trust, and sent to the constellation of GnuPG key-servers in the first place
Going even further, and revoking the keys is 'fly-specking' overkill
I have no problem with removing keys not _used_ on a given host (such information being able to be compiled out of the RPM database)
I don't really consider this a thing about saving space or making the output of 'rpm -qa' look nicer or something, but rather being good users of GPG. If we create and then phase out signing keys, then part of our process should also involve sending revocations for the old keys. And that process could be automated by a dnf plugin too. Leaving old keys around on the system for verification purposes presents a risk should the old key become compromised.
On Tue, Oct 31, 2017 at 3:06 PM David Cantrell dcantrell@redhat.com wrote:
On 10/31/2017 11:32 AM, R P Herrold wrote:
On Tue, 31 Oct 2017, David Cantrell wrote:
# rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l 64
Do we issue revocations for old keys? If not, let's do that and extend dnf to honor those and clean up?
What is the 'use case' for potentially preventing installation against a already know key of a existing, but older 'noarch' package; or one unpacking an older SRPM and NOT getting the scary NOKEY warning? The size of the keys is trivial, even though they do tend to accrete in a 'long running' instance
heck, I'll wager mostly those keys are never countersigned into a web of trust, and sent to the constellation of GnuPG key-servers in the first place
Going even further, and revoking the keys is 'fly-specking' overkill
I have no problem with removing keys not _used_ on a given host (such information being able to be compiled out of the RPM database)
I don't really consider this a thing about saving space or making the output of 'rpm -qa' look nicer or something, but rather being good users of GPG. If we create and then phase out signing keys, then part of our process should also involve sending revocations for the old keys. And that process could be automated by a dnf plugin too. Leaving old keys around on the system for verification purposes presents a risk should the old key become compromised.
Why wouldn't the keys have expiration dates, following best practices? An expired key is a bit friendlier of a nudge off of using outdated and unsupported RPMs than a revoked key, which indicates a potential compromise. I would expect any GPG keys for Fedora versions older than EOL+5 or EOL+10 years to have already expired. Is that not the case?
On 10/31/2017 04:08 PM, Christopher wrote:
On Tue, Oct 31, 2017 at 3:06 PM David Cantrell <dcantrell@redhat.com mailto:dcantrell@redhat.com> wrote:
On 10/31/2017 11:32 AM, R P Herrold wrote: > On Tue, 31 Oct 2017, David Cantrell wrote: > >>> # rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l >>> 64 >> >> Do we issue revocations for old keys? If not, let's do that and extend >> dnf to honor those and clean up? > > What is the 'use case' for potentially preventing installation > against a already know key of a existing, but older 'noarch' > package; or one unpacking an older SRPM and NOT getting the > scary NOKEY warning? The size of the keys is trivial, even > though they do tend to accrete in a 'long running' instance > > heck, I'll wager mostly those keys are never countersigned > into a web of trust, and sent to the constellation of GnuPG > key-servers in the first place > > Going even further, and revoking the keys is 'fly-specking' > overkill > > I have no problem with removing keys not _used_ on a given > host (such information being able to be compiled out of the > RPM database) I don't really consider this a thing about saving space or making the output of 'rpm -qa' look nicer or something, but rather being good users of GPG. If we create and then phase out signing keys, then part of our process should also involve sending revocations for the old keys. And that process could be automated by a dnf plugin too. Leaving old keys around on the system for verification purposes presents a risk should the old key become compromised.Why wouldn't the keys have expiration dates, following best practices? An expired key is a bit friendlier of a nudge off of using outdated and unsupported RPMs than a revoked key, which indicates a potential compromise. I would expect any GPG keys for Fedora versions older than EOL+5 or EOL+10 years to have already expired. Is that not the case?
I don't know if the keys have expiration dates or not, but that would be effective too. And our packaging tools could clean things up based on that information as well.
On 10/31/2017 01:08 PM, Christopher wrote:
Why wouldn't the keys have expiration dates, following best practices? An expired key is a bit friendlier of a nudge off of using outdated and unsupported RPMs than a revoked key, which indicates a potential compromise. I would expect any GPG keys for Fedora versions older than EOL+5 or EOL+10 years to have already expired. Is that not the case?
nope. It's not the case and it also largely doesn't matter.
So, a few facts to toss on the thread:
* All our keys that have been generated by sigul (which I think is all of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both retired now) don't set expiration dates.
* EPEL-5's key did have a 10 year expiration, and did expire early this year before it went end of life. Turns out the only thing that cared about that was sigul. yum doesn't check, rpm doesn't check, they happily keep using the expired key.
* I've tried to sign the Fedora gpg keys in the past, but I'm really not sure it's worth it. IMHO gpg is kind of a dead end. It's hopelessly complex, no one bothers to use the web of trust as it was intended, it integrates very poorly with everything and only geeks use it.
* Currently we don't do anything to make things difficult for EOL users. When a release goes EOL we archive it, but we continue to serve it in mirrormanager (now pointing to the archives) and we don't do anything with the keys. If we wish to do something like this, it should likely be a decision for FESCo and/or the Council. Changing this may annoy a large number of people. :)
I personally don't see much advantage in expiring old keys or the like. The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or download your resigned package and have them accept the key or any number of things.
kevin
On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi kevin@scrye.com wrote:
On 10/31/2017 01:08 PM, Christopher wrote:
Why wouldn't the keys have expiration dates, following best practices? An expired key is a bit friendlier of a nudge off of using outdated and unsupported RPMs than a revoked key, which indicates a potential compromise. I would expect any GPG keys for Fedora versions older than EOL+5 or EOL+10 years to have already expired. Is that not the case?
nope. It's not the case and it also largely doesn't matter.
So, a few facts to toss on the thread:
- All our keys that have been generated by sigul (which I think is all
of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both retired now) don't set expiration dates.
Is it possible to change that behavior?
- EPEL-5's key did have a 10 year expiration, and did expire early this
year before it went end of life. Turns out the only thing that cared about that was sigul. yum doesn't check, rpm doesn't check, they happily keep using the expired key.
I think that's what's being proposed to be fixed. rpm and/or yum should check. I'm actually not sure I'm on board with that idea, though, because as you point out further down, the old releases are still served in mirrors, and could still be in use. I'm more concerned about following best practices to set expiration dates, so that a key cannot be used past a certain date to continue to sign new artifacts, unintentionally. Extremely long-lived keys increase the liklihood that they are using older generation algorithms which could be broken, weak algorithms, or simply due to their age they're old enough to have been brute-forced. I don't know that we should do anything on the verification or cleanup end of things, but setting an expiration date seems reasonable to me.
- I've tried to sign the Fedora gpg keys in the past, but I'm really not
sure it's worth it. IMHO gpg is kind of a dead end. It's hopelessly complex, no one bothers to use the web of trust as it was intended, it integrates very poorly with everything and only geeks use it.
One might argue that only geeks use Fedora or Linux in general, so I'm not sure that's much of a relevant point. The fact is GPG is used to sign RPMs, which are used by Fedora, so using GPG well is still relevant.
- Currently we don't do anything to make things difficult for EOL users.
When a release goes EOL we archive it, but we continue to serve it in mirrormanager (now pointing to the archives) and we don't do anything with the keys. If we wish to do something like this, it should likely be a decision for FESCo and/or the Council. Changing this may annoy a large number of people. :)
I think setting EOL+10 year expiration date would probably annoy nobody if the verification simply produced a warning about age and didn't actually cause anything to fail.
I personally don't see much advantage in expiring old keys or the like. The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or download your resigned package and have them accept the key or any number of things.
Yeah, that's the attack vector I was thinking. It's also the case that somebody could be tricked into installing an older version of a patched package from the current release, which is signed by the same GPG key. So, maybe it's not much of a mitigation of anything. Still, I think adding a reasonable expiration date is good practice... and warning during verification (or making a verification policy configurable in yum/dnf) might be a good idea.
On 11/01/2017 01:07 PM, Christopher wrote:
On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi kevin@scrye.com wrote:
On 10/31/2017 01:08 PM, Christopher wrote:
Why wouldn't the keys have expiration dates, following best practices? An expired key is a bit friendlier of a nudge off of using outdated and unsupported RPMs than a revoked key, which indicates a potential compromise. I would expect any GPG keys for Fedora versions older than EOL+5 or EOL+10 years to have already expired. Is that not the case?
nope. It's not the case and it also largely doesn't matter.
So, a few facts to toss on the thread:
- All our keys that have been generated by sigul (which I think is all
of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both retired now) don't set expiration dates.
Is it possible to change that behavior?
Sure. Would require an RFE against sigul and code/work to implement, but it should be possible.
...snip...
I think setting EOL+10 year expiration date would probably annoy nobody if the verification simply produced a warning about age and didn't actually cause anything to fail.
I think going to all the work of implementing that would waste a lot of peoples time and cause EOL using people to change nothing.
I personally don't see much advantage in expiring old keys or the like. The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or download your resigned package and have them accept the key or any number of things.
Yeah, that's the attack vector I was thinking. It's also the case that somebody could be tricked into installing an older version of a patched package from the current release, which is signed by the same GPG key. So, maybe it's not much of a mitigation of anything. Still, I think adding a reasonable expiration date is good practice... and warning during verification (or making a verification policy configurable in yum/dnf) might be a good idea.
Well, feel free to file RFE's on yum/rpm/dnf, but I suspect they have lots of more important things to implement.
kevin
On 11/01/2017 10:37 PM, Kevin Fenzi wrote:
On 11/01/2017 01:07 PM, Christopher wrote:
On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi kevin@scrye.com wrote:
On 10/31/2017 01:08 PM, Christopher wrote:
[...]
I personally don't see much advantage in expiring old keys or the like. The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or download your resigned package and have them accept the key or any number of things.
Yeah, that's the attack vector I was thinking. It's also the case that somebody could be tricked into installing an older version of a patched package from the current release, which is signed by the same GPG key. So, maybe it's not much of a mitigation of anything. Still, I think adding a reasonable expiration date is good practice... and warning during verification (or making a verification policy configurable in yum/dnf) might be a good idea.
Well, feel free to file RFE's on yum/rpm/dnf, but I suspect they have lots of more important things to implement.
I actually mostly implemented OpenPGP expiry for rpm last spring, but never never pushed it upstream because in the end it seemed so ... meh.
Yeah it could be made to warn at install-time, to what benefit really? It's better to have rpm verify the expired signature than have people use --nosignature to shut up annoying warnings.
- Panu -
On 11/01/2017 03:14 PM, Kevin Fenzi wrote:
The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or
Is it possible to compromise an old key, and use it to sign new malware that looks like it is from a recent distribution? I understand that it's unlikely because private keys are protected equally well regardless whether they are old or new, but maybe there's some way that makes older keys more vulnerable?
On 11/01/2017 01:19 PM, Przemek Klosowski wrote:
On 11/01/2017 03:14 PM, Kevin Fenzi wrote:
The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or
Is it possible to compromise an old key, and use it to sign new malware that looks like it is from a recent distribution?
Well, rpm doesn't care what a file is named... you can make a foobar-1.0.fc30.x86_64.rpm signed by any key you want. That said, you would have to trick someone into downloading and installing it.
I understand that it's unlikely because private keys are protected equally well regardless whether they are old or new, but maybe there's some way that makes older keys more vulnerable?
Sure, older keys are likely less bits (I don't recall). So it's more likely someone could brute force them somehow or the like. As far as I know even 1024 bit gpg keys are not brute forceable currently.
kevin
On Wed, Nov 1, 2017 at 3:31 PM Przemek Klosowski przemek.klosowski@nist.gov wrote:
On 11/01/2017 03:14 PM, Kevin Fenzi wrote:
The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or
Is it possible to compromise an old key, and use it to sign new malware that looks like it is from a recent distribution? I understand that it's unlikely because private keys are protected equally well regardless whether they are old or new, but maybe there's some way that makes older keys more vulnerable?
Given the way sigul stores the private keys no. No one actually has access to the password for the private key if you could manage to extract the key. The biggest threat would be someone managing to recreate an old key. Even then, the biggest risk is long lived machines, as new installs never import the old keys by default. That does not mean someone couldn't just import all the old keys into their system. Prior to Fedora moving to Sigul there was a shared key and passphrase for signing the rpms, sigula manages all acecss to the keys today
Dennis
Kevin Fenzi writes:
I personally don't see much advantage in expiring old keys or the like. The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or download your resigned package and have them accept the key or any number of things.
I don't think much of expiring either. But keys for prior releases should simply be removed, as part of the upgrade process, or on the first boot after a successfull upgrade.
Now, if we go this way, we have to make sure we don't turn a bad situation into worse one. It's possible that a botched upgrade might end up with a system that's still bootable, so prior releases pgp keys should be left alone until it's known that fedup did its job successfully.
But once an upgrade is complete, prior release's pgp keys have absolutely no value in them, whatsoever, except as an additional potential compromise vector.
On 11/01/2017 11:51 PM, Sam Varshavchik wrote:
I don't think much of expiring either. But keys for prior releases should simply be removed, as part of the upgrade process, or on the first boot after a successfull upgrade.
Now, if we go this way, we have to make sure we don't turn a bad situation into worse one. It's possible that a botched upgrade might end up with a system that's still bootable, so prior releases pgp keys should be left alone until it's known that fedup did its job successfully.
But once an upgrade is complete, prior release's pgp keys have absolutely no value in them, whatsoever, except as an additional potential compromise vector.
Packages that was built for older releases are still distributed and used in newer versions.
Example: A package built for Fedora 24, signed with the Fedora 25 key, running on my Fedora 26 setup.
$ gpg2 < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096 2016-03-31 [SCE] C437DCCD558A66A37D6F43724089D8F2FDB19C98 uid Fedora 25 Primary (25) fedora-25-primary@fedoraproject.org
$ rpm -qi maven-shared-io Name : maven-shared-io Epoch : 1 Version : 3.0.0 Release : 2.fc24 Architecture: noarch Install Date: Sat 29 Oct 2016 12:26:04 AM CEST Group : Unspecified Size : 64077 License : ASL 2.0 Signature : RSA/SHA256, Sat 02 Apr 2016 12:12:02 AM CEST, Key ID 4089d8f2fdb19c98 Source RPM : maven-shared-io-3.0.0-2.fc24.src.rpm Build Date : Thu 04 Feb 2016 10:36:28 AM CET Build Host : arm01-builder21.arm.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://maven.apache.org/shared/maven-shared-io Summary : API for I/O support like logging, download or file scanning Description : API for I/O support like logging, download or file scanning.
$ cat /etc/fedora-release Fedora release 26 (Twenty Six)
Jonny Heggheim writes:
On 11/01/2017 11:51 PM, Sam Varshavchik wrote:
I don't think much of expiring either. But keys for prior releases should simply be removed, as part of the upgrade process, or on the first boot after a successfull upgrade.
Now, if we go this way, we have to make sure we don't turn a bad situation into worse one. It's possible that a botched upgrade might end up with a system that's still bootable, so prior releases pgp keys should be left alone until it's known that fedup did its job successfully.
But once an upgrade is complete, prior release's pgp keys have absolutely no value in them, whatsoever, except as an additional potential compromise vector.
Packages that was built for older releases are still distributed and used in newer versions.
So? They're simply signed by the newer release's PGP key. Big deal.
Example: A package built for Fedora 24, signed with the Fedora 25 key, running on my Fedora 26 setup.
$ gpg2 < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096 2016-03-31 [SCE] C437DCCD558A66A37D6F43724089D8F2FDB19C98 uid Fedora 25 Primary (25) fedora-25-primary@fedoraproject.org
$ rpm -qi maven-shared-io Name : maven-shared-io Epoch : 1 Version : 3.0.0 Release : 2.fc24 Architecture: noarch Install Date: Sat 29 Oct 2016 12:26:04 AM CEST
==============================================
Fedora 26 did not exist in October 2016. As such, it would be logically impossible for this package to have been installed from the Fedora 26 repository. You installed this package when you were running Fedora 25.
And removing Fedora 24/25th PGP key should have no effect, whatsoever, on currently-installed packages. PGP keys are checked only when a package gets installed. Once installed, nothing really cares about PGP signatures, and it wouldn't always be possible to verify it anyway, since config files installed by the package could obviously be changed, filestamps could be changed, etc…
I do see that maven-shared-io-3.0.0-2.fc24.src.rpm is, apparently, in the Fedora 26 repository:
[mrsam@thinkpad tmp]$ dnf download maven-shared-io Last metadata expiration check: 0:00:00 ago on Wed 01 Nov 2017 08:33:50 PM EDT. maven-shared-io-3.0.0-2.fc24.noarch.rpm 143 kB/s | 50 kB 00:00 [mrsam@thinkpad tmp]$ rpm --checksig maven-shared-io-3.0.0-2.fc24.noarch.rpm maven-shared-io-3.0.0-2.fc24.noarch.rpm: rsa sha1 (md5) pgp md5 OK
I have only Fedora 26 PGP keys installed:
[mrsam@thinkpad tmp]$ rpm -qa gpg-pubkey gpg-pubkey-3276f4b3-582f2526 gpg-pubkey-64dab85d-57d33e22 gpg-pubkey-9690e4af-582f231f
You can confirm, yourself, that these are Fedora and RPM fusion 26 keys.
I would not be able to verify the pgp signature on this package, unless it's signed by one of the keys I have installed.
Therefore, the Fedora 26 repo must be carrying this package signed by the Fedora 26 PGP key. Otherwise I could not possibly install it, obviously.
For final proof, you can download this package from the Fedora 24, 25, and 26 repos, separately, and verify that they're not binary identical, because each package carries a different PGP signature inside it. But this can be someone else's homework assignment. IIRC, the PGP signature is at the tail end of the rpm file, so I expect the actual binary files to be binary- identical until the last dozen, or so bytes. I don't know if rpm file format supports multiple signatures, and whether a new signature replaces the rpm file's existig one, or adds to it, and I'm too lazy to check right now. If the file sizes are different, it must mean that the F25/F26 sigs were tacked onto this package. If the file sizes are identical, it means that a new signature replaces the existing one.
Either way, removing old Fedora PGP keys should have absolutely zero impact.
David Cantrell writes:
I don't really consider this a thing about saving space or making the output of 'rpm -qa' look nicer or something, but rather being good users of GPG. If we create and then phase out signing keys, then part of our process should also involve sending revocations for the old keys. And that process could be automated by a dnf plugin too. Leaving old keys around on the system for verification purposes presents a risk should the old key become compromised.
Pretty sure I recall that a signing key was potentially compromised, some years ago, and the entire distro had to be re-signed with a new key.
… Yup. Just checked. Fedora 9 had to be re-signed with a new pgp key.
How quickly people forget.
Personally, every few releases I've manually gone through, and nuked old repo keys.
On 10/31/2017 04:15 PM, Sam Varshavchik wrote:
David Cantrell writes:
I don't really consider this a thing about saving space or making the output of 'rpm -qa' look nicer or something, but rather being good users of GPG. If we create and then phase out signing keys, then part of our process should also involve sending revocations for the old keys. And that process could be automated by a dnf plugin too. Leaving old keys around on the system for verification purposes presents a risk should the old key become compromised.
Pretty sure I recall that a signing key was potentially compromised, some years ago, and the entire distro had to be re-signed with a new key.
Indeed. It has happened. It was very frustrating.
… Yup. Just checked. Fedora 9 had to be re-signed with a new pgp key.
How quickly people forget.
It's very easy to forget.
Personally, every few releases I've manually gone through, and nuked old repo keys.
And I think a lot of us tend to do that sort of housekeeping work, which was sort of the point of my response. We could make that a little better in our tools (if it's not already there in some capacity).
Thanks,
On Tue, 31 Oct 2017, David Cantrell wrote:
I don't really consider this a thing about saving space or making the output of 'rpm -qa' look nicer or something, but rather being good users of GPG.
As noted but not addressed, which keys actually have been signed at GnuPG key-signing WoT 'parties? Which are presently on the public key-server constellation?
The answer:
Of the 38 keys on: https://getfedora.org/keys/ and https://getfedora.org/keys/obsolete.html ZERO are -- one (0xF5282EE4) seems to be a collision artifact [1]
If we create and then phase out signing keys, then part of our process should also involve sending revocations for the old keys.
but the ** private keys ** were never released or public anyway ... Revoking a ** public key ** (which is the keys in the RPM db in discussion) is useless as all it permitted doing was (and is) verifying that a proper private key existed at a place and point in time to sign that package. It is EPEL (thus at least one part of fedora) practice to do so already
And that process could be automated by a dnf plugin too. Leaving old keys around on the system for verification purposes presents a risk should the old key become compromised.
so shred the HSM holding the private key ...
This thread is time wasting and posturing
-- Russ herrold
1. the audit script is at: http://gallery.herrold.com/stuff/harvest-keys.sh
On 10/31/2017 03:52 AM, Miroslav Suchý wrote:
And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?
I'd be all for cleaning up old keys.
However, I would be cautious to not delete keys that are still in use. Example: User has Fedora 29 installed and has a package from Fedora 21 still installed as it was retired, but it has no dependencies that would cause it to fail.
On Tue, Oct 31, 2017 at 10:49 AM Michael Cronenworth mike@cchtml.com wrote:
On 10/31/2017 03:52 AM, Miroslav Suchý wrote:
And I wonder: is it a good idea to keep old gpg keys in RPM db? Or
should we automate the removal of old keys?
I'd be all for cleaning up old keys.
However, I would be cautious to not delete keys that are still in use. Example: User has Fedora 29 installed and has a package from Fedora 21 still installed as it was retired, but it has no dependencies that would cause it to fail.
Correct me if I'm wrong, but we only check keys at installation time, so they'd be able to continue running just fine, but they'd be denied if they tried to reinstall it after F21 is EOL. Which seems perfectly reasonable to me; if you're using an EOL operating system, forcing people to have to pass --no-gpgcheck is a great way to get them to pause and reconsider their situation.
On 10/31/2017 04:57 PM, Stephen Gallagher wrote:
On Tue, Oct 31, 2017 at 10:49 AM Michael Cronenworth <mike@cchtml.com mailto:mike@cchtml.com> wrote:
On 10/31/2017 03:52 AM, Miroslav Suchý wrote: > And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? I'd be all for cleaning up old keys. However, I would be cautious to not delete keys that are still in use. Example: User has Fedora 29 installed and has a package from Fedora 21 still installed as it was retired, but it has no dependencies that would cause it to fail.Correct me if I'm wrong, but we only check keys at installation time, so they'd be able to continue running just fine, but they'd be denied if they tried to reinstall it after F21 is EOL. Which seems perfectly reasonable to me; if you're using an EOL operating system, forcing people to have to pass --no-gpgcheck is a great way to get them to pause and reconsider their situation.
Actually rpm by default checks signatures on queries and verification too, so there is some value in keeping the keys there, at least for keys that are actually in use.
- Panu -
On Tue, 2017-10-31 at 17:34 +0200, Panu Matilainen wrote:
On 10/31/2017 04:57 PM, Stephen Gallagher wrote:
On Tue, Oct 31, 2017 at 10:49 AM Michael Cronenworth <mike@cchtml.c om mailto:mike@cchtml.com> wrote:
On 10/31/2017 03:52 AM, Miroslav Suchý wrote: > And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?
I'd be all for cleaning up old keys.
However, I would be cautious to not delete keys that are still in use. Example: User has Fedora 29 installed and has a package from Fedora 21 still installed as it was retired, but it has no dependencies that would cause it to fail.
Correct me if I'm wrong, but we only check keys at installation time, so they'd be able to continue running just fine, but they'd be denied if they tried to reinstall it after F21 is EOL. Which seems perfectly reasonable to me; if you're using an EOL operating system, forcing people to have to pass --no-gpgcheck is a great way to get them to pause and reconsider their situation.
Actually rpm by default checks signatures on queries and verification too, so there is some value in keeping the keys there, at least for keys that are actually in use.
Is it possible to mark keys so they can be used for verification but not for installation of new packages ?
My personal worry is that old keys may get compromised over time, so it is a very good practice to regularly "disable" old keys.
Simo.
On 31/10/17 18:46, Simo Sorce wrote:
On Tue, 2017-10-31 at 17:34 +0200, Panu Matilainen wrote:
On 10/31/2017 04:57 PM, Stephen Gallagher wrote:
[...snip...]
Correct me if I'm wrong, but we only check keys at installation time, so they'd be able to continue running just fine, but they'd be denied if they tried to reinstall it after F21 is EOL. Which seems perfectly reasonable to me; if you're using an EOL operating system, forcing people to have to pass --no-gpgcheck is a great way to get them to pause and reconsider their situation.
Actually rpm by default checks signatures on queries and verification too, so there is some value in keeping the keys there, at least for keys that are actually in use.
Is it possible to mark keys so they can be used for verification but not for installation of new packages ?
Can't key revocation status be used for this? IIRC, it is possible to verify existing signatures with revoked keys, so yum/dnf just need reject doing verification during install if the key is revoked.
My personal worry is that old keys may get compromised over time, so it is a very good practice to regularly "disable" old keys.
+1
I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-rem... with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-fr... And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?
Yes, I'm replying to this old thread. See it in the list archives. And, since then, doesn't look much has changed. Old pgp keys are still gathering dust, in everyone's rpm databases.
I had nothing else to do this lazy Sunday afternoon, so I finally decided to do something about it. This cleaned up over 40 old PGP keys from one of my laptop:
Dne 03. 05. 21 v 0:18 Sam Varshavchik napsal(a):
Yes, I'm replying to this old thread. See it in the list archives. And, since then, doesn't look much has changed. Old pgp keys are still gathering dust, in everyone's rpm databases.
I had nothing else to do this lazy Sunday afternoon, so I finally decided to do something about it. This cleaned up over 40 old PGP keys from one of my laptop:
You inspired me to do:
https://github.com/xsuchy/fedora-upgrade/commit/138fa54b62c633c6435a86eaf53b...
Although I chosen to remove only enumerated keys.
Miroslav
Miroslav Suchý writes:
Dne 03. 05. 21 v 0:18 Sam Varshavchik napsal(a):
Yes, I'm replying to this old thread. See it in the list archives. And, since then, doesn't look much has changed. Old pgp keys are still gathering dust, in everyone's rpm databases.
I had nothing else to do this lazy Sunday afternoon, so I finally decided to do something about it. This cleaned up over 40 old PGP keys from one of my laptop:
You inspired me to do:
https://github.com/xsuchy/fedora-upgrade/commit/ 138fa54b62c633c6435a86eaf53b0ed44ae48fe5
Although I chosen to remove only enumerated keys.
Yeah, so:
1) Someone has to remember to do this as part of every release
2) This doesn't do anything about add-on repositories' keys
3) I had pgp keys going all the way to F19, etc…
My approach is slightly awkward -- having to manually parse the conf files and perform release and arch substitution. But it has the advantage of pretty much figuring everything out. It also did me a favor and found some old conf files on one of my servers, that ages ago I used – my dim recollection – to do an upgrade from a throwaway local repo, and so the repo conf referenced keys that did not exist. It was nice to clean that up.
On Mon, May 03, 2021 at 11:06:44AM -0400, Sam Varshavchik wrote:
My approach is slightly awkward -- having to manually parse the conf files and perform release and arch substitution. But it has the advantage of pretty much figuring everything out. It also did me a favor and found some old conf files on one of my servers, that ages ago I used – my dim recollection – to do an upgrade from a throwaway local repo, and so the repo conf referenced keys that did not exist. It was nice to clean that up.
Another thing you can do is just `sudo rpm -e --allmatches gpg-pubkey` and then add back manually when DNF next prompts you. I'm not sure if there's a way to tell DNF to prompt for all current keys other than as a side-effect of wanting to install a package....
Dne 03. 05. 21 v 17:06 Sam Varshavchik napsal(a):
Yeah, so:
Someone has to remember to do this as part of every release
This doesn't do anything about add-on repositories' keys
I had pgp keys going all the way to F19, etc…
My approach is slightly awkward
*nod* would you mind add clean-rpm-gpg-pubkey to Fedora? Then I can simply call it.
Miroslav
Miroslav Suchý writes:
Dne 03. 05. 21 v 17:06 Sam Varshavchik napsal(a):
Yeah, so:
Someone has to remember to do this as part of every release
This doesn't do anything about add-on repositories' keys
I had pgp keys going all the way to F19, etc…
My approach is slightly awkward
*nod* would you mind add clean-rpm-gpg-pubkey to Fedora? Then I can simply call it.
It's been a long, long time since I packaged something. Life happens, etc… We'll see, can't make any promises…
*nod* would you mind add clean-rpm-gpg-pubkey to Fedora? Then I can simply call it.
Here's a package review request for it: https://bugzilla.redhat.com/show_bug.cgi?id=2294337
-
Christopher -
David Cantrell -
David Sommerseth -
Dennis Gilmore -
Jonny Heggheim -
Kevin Fenzi -
Matthew Miller -
Michael Cronenworth -
Miroslav Suchý -
Panu Matilainen -
Peter Oliver -
Przemek Klosowski -
R P Herrold -
Roberto Ragusa -
Sam Varshavchik -
Simo Sorce -
Stephen Gallagher