Having now updated our in-code, expiration extended, public GPG/PGP key (for rpm and repo signature validation), we have a requirement to work-around an apparent upstream blocking bug where rpm --import extended-key which we already enact, fails silently to import the extended key.

Reproducer:

rpm -qa gpg-pubkey* | wc -l
7
rpm -qi gpg-pubkey-5f043187-5ed2a099  # the existing key's rpm package at that time.
# Indicates info for pre-extended key
rpm --import https://rockstor.com/ROCKSTOR-GPG-KEY
# no new keys and existing 5f043187-5ed2a099 key package description shows old key still.
rpm -qa gpg-pubkey* | wc -l
7

Where-as if we first remove the pre-extended key and try-again to import the new key:

rpm -qa gpg-pubkey* | wc -l
7
rpm --erase gpg-pubkey-5f043187-5ed2a099
rpm -qa gpg-pubkey* | wc -l
6
rpm --import https://rockstor.com/ROCKSTOR-GPG-KEY
rpm -qa gpg-pubkey* | wc -l
7

The new extended key's rpm 'package' has been seen as unchanged at "gpg-pubkey-5f043187-5ed2a099", but also as "gpg-pubkey-5f043187-68331efe with the two hexdecimal blocks in the name correspond to Version & Release:

rpm -qi gpg-pubkey-5f043187
Name        : gpg-pubkey
Version     : 5f043187
Release     : 68331efe

It is proposed that we add a force erase of our Private key (referenced by version) and re-instate from our in-code instance after very rpm update.
This way we can ensure an older import does not block the import of an update of the in-code public key delivered by rpm; as per:

• Update public GPG key Update public GPG key #2986 Update public GPG key #2986 #2987