[MDEV-29844] SLES12 MariaDB repo now using unknown signing key Created: 2022-10-21  Updated: 2022-10-21  Resolved: 2022-10-21

Status: Closed
Project: MariaDB Server
Component/s: Packaging, Repositories
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: David Shapiro Assignee: Daniel Bartholomew
Resolution: Fixed Votes: 0
Labels: None


 Description   

It looks like sometime within the last 24 hours, the SLES12 MariaDB repo at https://downloads.mariadb.com/MariaDB/mariadb-10.5/yum/sles/12/x86_64 changed signing keys, but no new key appears to have been published anywhere.

We have SMT repo servers which mirror this repository, and after the latest mirroring at ~1:20AM UTC on 10/21/2022, the contents of the repo appear to have changed signing keys.

All attempts contact any of our SMT servers (e.g. just running zypper refresh) now report the following:
—
Retrieving repository 'mariadb_repository' metadata [.
Warning: File 'repomd.xml' from repository 'mariadb_repository' is signed with an unknown key 'F1656F24C74CD1D8'.

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' is signed with an unknown key 'F1656F24C74CD1D8'. Continue? [yes/no] (no): Cannot read input: bad stream or EOF.
If you run zypper without a terminal, use '--non-interactive' global
option to make zypper use default answers to prompts.
error]
Repository 'mariadb_repository' is invalid.
[...] Valid metadata not found at specified URL
Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'mariadb_repository' because of the above error.
—

This problem is not specific to a single SMT server. All our SMT servers which mirrored overnight manifest this same problem.

I've checked the GPG keys posted at the following locations:

These are all the same key we already have, and not whatever key is currently in use by the MariaDB repository.

Was this signing key switch intentional? If so, the new key needs to be published. If not, the contents of the repo are currently signed incorrectly.

 Comments   
Comment by Daniel Bartholomew [ 2022-10-21 ]

This was an error with staging. I've triggered a restore from a backup of the repository to get it restored. Thanks.

Comment by Daniel Bartholomew [ 2022-10-21 ]

The repository should now be restored.

To expand a little on what happened. We were testing a repository update to address the fix for MDEV-29765 using a different key (actually the key we use for our Debian/Ubuntu repositories). The update was only supposed to go to our internal staging repositories for testing but it accidentally ended up being propagated to the old https://downloads.mariadb.com/MariaDB/ public site.

This process error aside, if we do end up switching over to using a different signing key we will announce and publish it ahead of time. Thanks.

Comment by David Shapiro [ 2022-10-21 ]

That worked. I re-mirrored one of our SMT servers, and saw a bunch of updates from MariaDB go by in the log. Clients of that SMT server no longer report this error.

Thanks.

Generated at Thu Feb 08 10:11:43 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.