The GPG key that is currently used for our APT repository expires on March 4th, 2018. We want to take this opportunity to rotate the GPG key.
When we rotate our GPG key (on Tuesday, Feb 27, 2018), all customers who use our APT repo will need to have the new key trusted by APT on every machine to continue installing or upgrading the Agent.
The new GPG key should already be trusted on the vast majority of our customers’ machines. We have been pushing out the new key via various channels for over a year. This documentation will provide information on what steps you may need to take.
The GPG key that we currently use (referred to here as the “deprecated” GPG key) expires on March 4th. If the public key expires while it’s still being used to sign our APT repo, all customers running
apt-get update on their servers would see an error from apt on our repository (KEYEXPIRED on our repository’s Release file), and wouldn’t be able to install or update the agent.
We could extend the expiration date of the current public key, but this would also require action from our customers anyway (running one command to pull the public key again, with the updated expiration date). Instead, we're using this as an opportunity to use the new set of keys we have, which we’ve had in “standby” for the past 18 months.
To be clear: the reason for this rotation is due to a key expiration, and NOT any sort of key exposure or other security incident.
Only customers using our APT repo (deb packages for Debian/Ubuntu) are affected.
Hosts that already trust the new key will transparently be able to use the repository after we switch to the new key, without any further action.
Hosts that do not trust the new key when we switch will see an error on our repository when they run apt-get update (W: GPG error: https://apt.datadoghq.com stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D3A80E30382E94DE). They won’t be able to install or update the Agent. Other APT repos won’t be affected however.
Since we’ve updated our installation methods about a year ago to make them trust both the current deprecated key and the new key, most of our customers shouldn’t need to take any action.
More precisely, the new key is already trusted if one of the following is true for the host:
- Chef: The Agent is installed with the official datadog cookbook, version 2.7.0 or higher
- Puppet: The Agent is installed with the official datadog_agent module, version 1.9.0 or higher
- Ansible: The Agent is installed with the official Datadog.datadog role, version 1.2.0 or higher
- One-line install script: The Agent is installed with our install script, downloaded after Oct 24, 2016
- The host is already running an Agent installed with through our deb package, Agent version 5.8.5 or higher. Please note that this condition alone does not guarantee that the new key is actually trusted, since the agent package tries to trust the new key but ignores failures (caused by network unavailability, unhandled proxies, etc.)
You can check if a host trusts the new key by running:
$ apt-key list | grep -A4 382E94DE
pub 4096R/382E94DE 2016-06-29 [expires: 2022-06-28]
uid Datadog, Inc <email@example.com>
sub 4096R/F432F6E0 2016-06-29 [expires: 2022-06-28]
sub 4096R/8387EEAF 2016-06-29 [expires: 2022-06-28]
sub 4096R/BFF6291E 2016-07-11 [expires: 2022-07-10]
This will return an empty output and non-zero exit code if the key is not trusted.
If apt on a host doesn’t trust the new key, you can run the following to make apt trust it:
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 A2923DFF56EDA6E76E55E492D3A80E30382E94DE
Please contact firstname.lastname@example.org with any questions you have about this.