Icinga uses it’s own repositories to distribute installation packages for the Icinga software. Today, we’re announcing the rotation of the GPG key used to sign our repositories and packages.
Currently, our repository is signed with a 1024 bit DSA key. Key rotation is necessary because 1024-bit DSA keys are now considered weak and no longer approved by FIPS 186-5 for digital signatures. Advances in computational power and the deprecation of older algorithms like DSA and SHA-1 have made it essential to transition to stronger, more secure keys. This ensures compliance with current security standards, avoids compatibility issues, and protects against potential future threats. Rotating to a more robust key is a crucial step in maintaining the security and integrity of our packages.
We will replace our GPG key with an RSA 4096 bit key. Additionally, we will (re-)sign both, the repository as a whole, and all packages with the new key. Re-signed existing package files will be moved in order to avoid checksum mismatches.
When will it be changed
The key will be changed on September 30, 2024.
The fingerprint of the new key is the following: DD3A F619 8ED0 00B4 C0B7 3956 CC11 6F55 AA7F 2382
Required Actions for Users of RHEL-like Distributions
By default, the package manager verifies the signatures of individual packages only. As a result, any changes will become apparent only when installing or updating packages. Packages that are already cached will appear absent, as the files are relocated. This will appear as follows:
# dnf install icinga2-doc [...] Total download size: 5.8 M Installed size: 8.3 M Is this ok [y/N]: y Downloading Packages: [MIRROR] icinga2-doc-2.13.2-1.el8.icinga.x86_64.rpm: Status code: 404 for http://10.27.3.24/rpm-current/icinga2-doc-2.13.2-1.el8.icinga.x86_64.rpm (IP: 10.27.3.24) [...]
Running dnf makecacheonce will fix this temporary issue.
All packages can now be downloaded and installed as usual. The package manager will prompt you once to import the new key. The following example illustrates how this will appear:
# dnf install icinga2-doc [...] Total download size: 5.8 M Installed size: 8.3 M Is this ok [y/N]: y Downloading Packages: [...] Importing GPG key 0xE27F4F33: [...] Is this ok [y/N]: y Key imported successfully Running transaction check [...]
Required Actions for Users of SLES and openSUSE
Packages that are already cached will appear absent, as the files are relocated. This will appear as follows:
# zypper in icinga2-doc [...] 1 new package to install. Overall download size: 5.8 MiB. Already cached: 0 B. After the operation, additional 8.3 MiB will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package icinga2-doc-2.13.2-1.el8.icinga.x86_64 (1/1), 5.8 MiB ( 8.3 MiB unpacked) Retrieving: icinga2-doc-2.13.2-1.el8.icinga.x86_64.rpm ..............[not found] File './icinga2-doc-2.13.2-1.el8.icinga.x86_64.rpm' not found on medium 'http://10.27.3.24/rpm-current/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): a
Running zypper ref once will resolve this temporary issue. However, these Linux distributions verify both the repository metadata and individual packages. When zypper ref refreshes the repository, it will detect the new key and prompt you to confirm whether to trust it:
# zypper ref [...] Looking for gpg key ID E27F4F33 in repository test. gpgkey=http://10.27.3.24/rpm-current/gpg.key New repository or package signing key received: [...] Do you want to reject the key, or trust always? [r/a/?] (r): a [...] All repositories have been refreshed.
All packages can now be downloaded and installed as usual.
Required Actions for Users of Debian and Ubuntu
The package manager verifies only the repository metadata signatures, so no files will be moved. However, unlike RPM distributions, keys are not automatically discovered. As a result, you will need to manually trust the new key. To do this, follow these steps to import the Icinga keyring package, which includes our GPG keys:
Install the new package icinga-archive-keyringwhich we published recently. Do this before our signature rotation, so you can install it with the old key! It will install both keys to /usr/share/keyrings/icinga-archive-keyring.gpg. Your /etc/apt/sources.list.d/*-icinga.listfile should already reference that keyring like this:
deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/debian icinga-bullseye main
If not, change it accordingly and run apt updateonce for verification afterwards. Now both keys are trusted and you can install packages as usual, regardless of our key rotation. After a reasonable amount of time, we will remove the old key from the keyring.
Required Actions for Users of their own Repository Mirrors
The required actions for Debian and Ubuntu are the same as above. For RPM distributions, you’ll also have to rotate the key file in your mirror as soon as we do. (For its location, see the gpgkey= parameter in your ICINGA-release.repofile.)
Required Actions for Users of EOL Distribution Versions
We will not re-sign packages for distribution versions that have reached their End-of-Life (EOL). Since our GPG key applies universally, its rotation will impact these EOL distributions as well (e.g., CentOS 7). Consequently, the new trusted key will no longer match the old package signatures.
Required actions for all End-of-Life RPM distributions:
- Download our old key as soon as possible or extract it via rpm(8).
- In your
ICINGA-release.repofile, letgpgkey=point to the old key.
Existing Debian and Ubuntu installations are not affected by this issue. However, for future installations, the old key will need to be imported instead of the current one.
In any case, we recommend upgrading to a supported OS version.
