Hi Folks,
OpenSSL in CentOS Stream and RHEL 9 intends to remove the sha1 algorithm, and recently a build landed that makes this change.
When that build first went to testing we noticed that the CentOS SIG rpm signing keys (including the one enabled by default for Extras) contained a sha1 signature on one of the subkeys, which caused trouble validating rpms.
We have begun to mitigate this by re-signing the offending subkey in the Extras signing key and are currently pushing a compose to the mirrors. If you've previously imported the Extras key (like if you've installed a SIG centos-release package on your system), you may notice messages during an rpm transaction like:
`Key import failed (code 2)`
followed by
`Error: GPG check FAILED`
To continue you will need to update to centos-gpg-keys-9.0-12.el9 (plus the corresponding centos-stream-release package) and perform a manual step:
`rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras-SHA512`
Since all of the SIG keys are affected as well, we are working on re-signing subkeys for those SIGs that are currently shipping content for CentOS Stream 9. We will post links to the updated pubkeys and SIG leaders will need to rebuild their centos-release packages to include these new keys. We expect references to those new keys to be published in the next couple of days.
If there are any questions please find us in #centos-devel or #centos-stream in libera, or reply here.
Cheers! --Brian
References: https://bugzilla.redhat.com/show_bug.cgi?id=2059424
On 03/03/2022 04:11, Brian Stinson wrote:
Hi Folks,
OpenSSL in CentOS Stream and RHEL 9 intends to remove the sha1 algorithm, and recently a build landed that makes this change.
When that build first went to testing we noticed that the CentOS SIG rpm signing keys (including the one enabled by default for Extras) contained a sha1 signature on one of the subkeys, which caused trouble validating rpms.
We have begun to mitigate this by re-signing the offending subkey in the Extras signing key and are currently pushing a compose to the mirrors. If you've previously imported the Extras key (like if you've installed a SIG centos-release package on your system), you may notice messages during an rpm transaction like:
`Key import failed (code 2)`
followed by
`Error: GPG check FAILED`
To continue you will need to update to centos-gpg-keys-9.0-12.el9 (plus the corresponding centos-stream-release package) and perform a manual step:
`rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras-SHA512`
Since all of the SIG keys are affected as well, we are working on re-signing subkeys for those SIGs that are currently shipping content for CentOS Stream 9. We will post links to the updated pubkeys and SIG leaders will need to rebuild their centos-release packages to include these new keys. We expect references to those new keys to be published in the next couple of days.
If there are any questions please find us in #centos-devel or #centos-stream in libera, or reply here.
Cheers! --Brian
References: https://bugzilla.redhat.com/show_bug.cgi?id=2059424
As a follow-up in this thread, all SIGs gpg public keys are now re-signed and available on https://www.centos.org/keys/
FWIW, this is the commit with the diff : https://git.centos.org/centos/centos.org/c/ea540d5b2eeebedaff28b0ef504b58304...
Worth knowing that nothing WRT private keys was changed, so only public keys now (including sub keys) signed with SHA512 (and default for the future) Also worth knowing that RPM packages signed in the past were already signed with SHA256, so we don't have to worry about SHA1 for rpm packages (already done in the past)
As Brian said above, that means that SIGs can now start rebuilding their -release pkgs for Stream 9 with the re-signed gpg pub key , and inform their users about the change and manual intervention
Il giorno gio 3 mar 2022 alle ore 09:15 Fabian Arrotin arrfab@centos.org ha scritto:
On 03/03/2022 04:11, Brian Stinson wrote:
Hi Folks,
OpenSSL in CentOS Stream and RHEL 9 intends to remove the sha1 algorithm, and recently a build landed that makes this change.
When that build first went to testing we noticed that the CentOS SIG rpm signing keys (including the one enabled by default for Extras) contained a sha1 signature on one of the subkeys, which caused trouble validating rpms.
We have begun to mitigate this by re-signing the offending subkey in the Extras signing key and are currently pushing a compose to the mirrors. If you've previously imported the Extras key (like if you've installed a SIG centos-release package on your system), you may notice messages during an rpm transaction like:
`Key import failed (code 2)`
followed by
`Error: GPG check FAILED`
To continue you will need to update to centos-gpg-keys-9.0-12.el9 (plus the corresponding centos-stream-release package) and perform a manual step:
`rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras-SHA512`
Since all of the SIG keys are affected as well, we are working on re-signing subkeys for those SIGs that are currently shipping content for CentOS Stream 9. We will post links to the updated pubkeys and SIG leaders will need to rebuild their centos-release packages to include these new keys. We expect references to those new keys to be published in the next couple of days.
If there are any questions please find us in #centos-devel or #centos-stream in libera, or reply here.
Cheers! --Brian
References: https://bugzilla.redhat.com/show_bug.cgi?id=2059424
As a follow-up in this thread, all SIGs gpg public keys are now re-signed and available on https://www.centos.org/keys/
FWIW, this is the commit with the diff :
https://git.centos.org/centos/centos.org/c/ea540d5b2eeebedaff28b0ef504b58304...
Worth knowing that nothing WRT private keys was changed, so only public keys now (including sub keys) signed with SHA512 (and default for the future) Also worth knowing that RPM packages signed in the past were already signed with SHA256, so we don't have to worry about SHA1 for rpm packages (already done in the past)
As Brian said above, that means that SIGs can now start rebuilding their -release pkgs for Stream 9 with the re-signed gpg pub key , and inform their users about the change and manual intervention
Thanks, starting to update Virt SIG
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 03/03/2022 09.15, Fabian Arrotin wrote:
On 03/03/2022 04:11, Brian Stinson wrote:
Hi Folks,
OpenSSL in CentOS Stream and RHEL 9 intends to remove the sha1 algorithm, and recently a build landed that makes this change.
When that build first went to testing we noticed that the CentOS SIG rpm signing keys (including the one enabled by default for Extras) contained a sha1 signature on one of the subkeys, which caused trouble validating rpms.
We have begun to mitigate this by re-signing the offending subkey in the Extras signing key and are currently pushing a compose to the mirrors. If you've previously imported the Extras key (like if you've installed a SIG centos-release package on your system), you may notice messages during an rpm transaction like:
`Key import failed (code 2)`
followed by
`Error: GPG check FAILED`
To continue you will need to update to centos-gpg-keys-9.0-12.el9 (plus the corresponding centos-stream-release package) and perform a manual step:
`rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras-SHA512`
Since all of the SIG keys are affected as well, we are working on re-signing subkeys for those SIGs that are currently shipping content for CentOS Stream 9. We will post links to the updated pubkeys and SIG leaders will need to rebuild their centos-release packages to include these new keys. We expect references to those new keys to be published in the next couple of days.
If there are any questions please find us in #centos-devel or #centos-stream in libera, or reply here.
Cheers! --Brian
References: https://bugzilla.redhat.com/show_bug.cgi?id=2059424
As a follow-up in this thread, all SIGs gpg public keys are now re-signed and available on https://www.centos.org/keys/
FWIW, this is the commit with the diff : https://git.centos.org/centos/centos.org/c/ea540d5b2eeebedaff28b0ef504b58304...
Worth knowing that nothing WRT private keys was changed, so only public keys now (including sub keys) signed with SHA512 (and default for the future) Also worth knowing that RPM packages signed in the past were already signed with SHA256, so we don't have to worry about SHA1 for rpm packages (already done in the past)
As Brian said above, that means that SIGs can now start rebuilding their -release pkgs for Stream 9 with the re-signed gpg pub key , and inform their users about the change and manual intervention
Thanks for the detailed information. Two follow-up questions from my side: 1. Looking at the change for centos-release [1] the old and new gpg public key (with and without suffix -SHA512) are now included in centos-gpg-keys. Is there a technical reason to have both versions of the key included or is it fine to simply replace the key (same name)?
2. Are the new gpg public keys working for EL8 (and EL7)? I'd like to avoid having different keys in centos-release-* and listed on https://www.centos.org/keys/.
Thanks!
[1]: https://gitlab.com/redhat/centos-stream/rpms/centos-release/-/commit/d11bd36...
On 03/03/2022 10:05, Peter Georg wrote:
On 03/03/2022 09.15, Fabian Arrotin wrote:
<snip>
Thanks for the detailed information. Two follow-up questions from my side:
- Looking at the change for centos-release [1] the old and new gpg
public key (with and without suffix -SHA512) are now included in centos-gpg-keys. Is there a technical reason to have both versions of the key included or is it fine to simply replace the key (same name)?
- Are the new gpg public keys working for EL8 (and EL7)? I'd like to
avoid having different keys in centos-release-* and listed on https://www.centos.org/keys/.
WRT 2, the previous key[s] can still be imported on new installs on el7/el8 as the change was only introduced in el9. But yes, I think it would be better to have the same file[s] distributed everywhere (don't forget that the gpg public key is the same, only signed with a different digest algo)