Error message we get from doing the above steps looks something like below.
testsles15sp4vm:/tmp # zypper ref
Note: The rpm database seems to contain old V3 version gpg keys which are meanwhile obsolete and
considered insecure:
gpg-pubkey-1bb943db-511147a9
To see details about a key call 'rpm -qi GPG-PUBKEY-VERSION'.
Unless you believe the key in question is still in use, you can remove it from the rpm database
calling 'rpm -e GPG-PUBKEY-VERSION'.
Repository 'SLE-Module-Basesystem15-SP4-Pool' is up to date.
Repository 'SLE-Module-Basesystem15-SP4-Updates' is up to date.
Repository 'SLE-Module-Containers15-SP4-Pool' is up to date.
Repository 'SLE-Module-Containers15-SP4-Updates' is up to date.
Repository 'SLE-Module-HPC15-SP4-Pool' is up to date.
Repository 'SLE-Module-HPC15-SP4-Updates' is up to date.
Repository 'SLE-Module-Legacy15-SP4-Pool' is up to date.
Repository 'SLE-Module-Legacy15-SP4-Updates' is up to date.
Repository 'SLE-Module-Packagehub-Subpackages15-SP4-Updates' is up to date.
Repository 'SLE-Module-Packagehub-Subpackages15-SP4-Pool' is up to date.
Repository 'SLE-Module-Public-Cloud15-SP4-Pool' is up to date.
Repository 'SLE-Module-Public-Cloud15-SP4-Updates' is up to date.
Repository 'SLE-Module-Server-Applications15-SP4-Pool' is up to date.
Repository 'SLE-Module-Server-Applications15-SP4-Updates' is up to date.
Repository 'SLE-Module-Web-Scripting15-SP4-Pool' is up to date.
Repository 'SLE-Module-Web-Scripting15-SP4-Updates' is up to date.
Repository 'SLE-Product-SLES15-SP4-Pool' is up to date.
Repository 'SLE-Product-SLES15-SP4-Updates' is up to date.
Repository 'SUSE-PackageHub-15-SP4-Backports-Pool' is up to date.
Repository 'SUSE-PackageHub-15-SP4-Pool' is up to date.
Looking for gpg key ID 1BB943DB in cache /var/cache/zypp/pubkeys.
Repository mariadb_repository_sles15 does not define additional 'gpgkey=' URLs.
Warning: File 'repomd.xml' from repository 'mariadb_repository_sles15' is signed with an unknown key 'CBCB082A1BB943DB'.
Note: Signing data enables the recipient to verify that no modifications occurred after the data
were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
and in extreme cases even to a system compromise.
Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the
whole repo.
Warning: We can't verify that no one meddled with this file, so it might not be trustworthy
anymore! You should not continue unless you know it's safe.
File 'repomd.xml' from repository 'mariadb_repository_sles15' is signed with an unknown key 'CBCB082A1BB943DB'. Continue? [yes/no] (no)
Looking further why this is happening only with MariaDB and not other third party repositories we have, we noticed this must be weak signature that is probably being blocked with FIPS now.
MariaDB is still using DSA/SHA1 for signing the packges while all other repositories we have on the system are using SHA256 at minimum.
rpm -qip ./MariaDB-server-10.5.17-1.x86_64.rpm
Name : MariaDB-server
Version : 10.5.17
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : Applications/Databases
Size : 132794741
License : GPLv2
Signature : DSA/SHA1, Fri Aug 1200:08:482022, Key ID cbcb082a1bb943db
rpm -qip ./emacs-nox-27.2-150400.1.49.x86_64.rpm
Name : emacs-nox
Version : 27.2
Release : 150400.1.49
Architecture: x86_64
Install Date: (not installed)
Group : Productivity/Text/Editors
Size : 15789584
License : GPL-3.0-or-later
Signature : RSA/SHA256, Thu May 1203:40:452022, Key ID 70af9e8139db7c82
Are there existing tickets or plans on fixing this issue? We need FIPS for compliance reasons and can't deploy using SLES15 SP4 for this reason.
Just to make sure I'm on the same page, is this expected behavior? Shouldn't older package also get re-signed with new key?
Amit Narkhede
added a comment - Hi Faustin, Thanks for the update.
I tried to point a VM so that it will fetch things from https://downloads.mariadb.com/MariaDB/mariadb-10.5/yum/sles/15/x86_64 and see that latest packages from that repo still had older signature.
Just to make sure I'm on the same page, is this expected behavior? Shouldn't older package also get re-signed with new key?
Hi amitnarkhede, yes that's normal since only the next release (that has been delayed) will use the new signature key (so, 10.5.19 in your case).
Faustin Lammler
added a comment - Hi amitnarkhede , yes that's normal since only the next release (that has been delayed) will use the new signature key (so, 10.5.19 in your case).
Thank you Daniel and Faustin for the help on this.
I can confirm that now things are working as expected and I was able to successfully deploy systems this morning. We can close this ticket.
Amit Narkhede
added a comment - Thank you Daniel and Faustin for the help on this.
I can confirm that now things are working as expected and I was able to successfully deploy systems this morning. We can close this ticket.
Major
Hi Faustin, Thanks for the update.
I tried to point a VM so that it will fetch things from https://downloads.mariadb.com/MariaDB/mariadb-10.5/yum/sles/15/x86_64 and see that latest packages from that repo still had older signature.
Just to make sure I'm on the same page, is this expected behavior? Shouldn't older package also get re-signed with new key?