CLOS-4377: drop legacy MariaDB key block from mariadb-Server-GPG-KEY#25
Open
prilr wants to merge 1 commit into
Open
Conversation
vendors.d/rpm-gpg/mariadb-Server-GPG-KEY shipped two PGP public-key blocks: an old GnuPG-1.4.14-era key (MariaDB Package Signing Key, fingerprint 199369E5 404BD5FC 7D2FE43B CBCB082A 1BB943DB, short ID 4ACC7220) and the modern MariaDB Signing Key F1656F24C74CD1D8. RPM 4.11.3 on CL7 cannot parse the old block: `rpm --import` exits 1 with "key 1 import failed" and bails before processing the second block. During leapp preupgrade, the target_userspace_creator actor imports every key under vendors.d/rpm-gpg/ into the el8 systemd-nspawn overlay; the mariadb key failure halts the whole workflow under the FailPhase policy, so Plesk's cloudlinux7to8 wrapper aborts with LeappPreupgradeRisksPreventedException and no formal inhibitor. Keep only the modern block. The package-signing key in the old block is unrelated to mariadb.sigs (which only lists ce1a3dd5e3c94f49 and f1656f24c74cd1d8), so dropping it has no impact on Leapp's signature matching. Customers running MariaDB already have the legacy key in their rpmdb from prior installs; new installations sign with the modern key. Bump leapp-data release to 0.3-9.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
vendors.d/rpm-gpg/mariadb-Server-GPG-KEY shipped two PGP public-key blocks: an old GnuPG-1.4.14-era key (MariaDB Package Signing Key, fingerprint 199369E5 404BD5FC 7D2FE43B CBCB082A 1BB943DB, short ID 4ACC7220) and the modern MariaDB Signing Key F1656F24C74CD1D8.
RPM 4.11.3 on CL7 cannot parse the old block:
rpm --importexits 1 with "key 1 import failed" and bails before processing the second block. During leapp preupgrade, the target_userspace_creator actor imports every key under vendors.d/rpm-gpg/ into the el8 systemd-nspawn overlay; the mariadb key failure halts the whole workflow under the FailPhase policy, so Plesk's cloudlinux7to8 wrapper aborts with LeappPreupgradeRisksPreventedException and no formal inhibitor.Keep only the modern block. The package-signing key in the old block is unrelated to mariadb.sigs (which only lists ce1a3dd5e3c94f49 and f1656f24c74cd1d8), so dropping it has no impact on Leapp's signature matching. Customers running MariaDB already have the legacy key in their rpmdb from prior installs; new installations sign with the modern key.