Quick Summary: Facing the dreaded `apt-key is deprecated` warning on Debian or Ubuntu? A senior engineer breaks down why it’s happening and provides three real-world solutions, from a quick battlefield patch to a permanent, architect-approved fix for your automation.

Stop Ignoring the ‘apt-key is deprecated’ Warning. Here’s How to Actually Fix It.

I remember it clear as day. 2 AM, a critical production deployment for our new microservice, and the CI/CD pipeline just… dies. The build for our base Docker image, something that had been working flawlessly for months, was suddenly failing on `apt-get update`. A junior engineer, bless his heart, was frantically trying to figure it out. The error log was screaming `W: http://… InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.` For a year, we’d all seen that warning and thought, “Eh, it’s just a warning.” That night, a minor OS update in the base image turned that warning into a hard build failure. That’s the thing about technical debt—it always comes calling, usually at the worst possible time.

So, What’s Actually Breaking? The “Why” Behind the Warning

For years, the way we added a third-party repository key was with `apt-key add`. It was simple, easy, and dangerously insecure. Think of `/etc/apt/trusted.gpg` as a master key ring for your entire server. When you added a key to it—say, for Docker’s repository—you were telling your system, “I trust this key to validate software from any repository, not just Docker’s.” If that one key was ever compromised, an attacker could potentially use it to serve you malicious packages pretending to be from a completely different, trusted repository. It was a single point of failure for your system’s integrity.

The new method is about isolation. Instead of a global trust store, we now store each repository’s key in a separate file (usually in `/usr/share/keyrings/`) and then explicitly tell the repository’s source file to use only that specific key for verification. It’s the principle of least privilege applied to your package manager. You’re no longer giving out a master key to the whole building; you’re giving a key that only opens one specific apartment door.

Three Ways to Slay This Dragon

Alright, enough theory. You’ve got a broken build or a server yelling at you. Let’s get this fixed. I’ll give you three paths, from the “get me out of this mess right now” fix to the way we do it in our production IaC pipelines at TechResolve.

Solution 1: The Battlefield Patch (Get It Working NOW)

Your `ci-build-agent-03` is down and you need it running five minutes ago. This is the quick and dirty fix. We’re going to manually download the GPG key, convert it, and put it where it needs to go. We’ll use Docker’s repository as a common example.

# 1. Create the target directory for keys if it doesn't exist
sudo mkdir -p /usr/share/keyrings

# 2. Download Docker's GPG key, de-armor it (convert from ASCII to binary), and save it
# We are downloading it to a specific, isolated file now.
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker.gpg

# 3. Modify your existing repository source file (or create a new one)
# This is the magic part: [signed-by=...]
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. Now, your update should work without the warning
sudo apt-get update

Warning: This is a great manual fix, but it’s not idempotent. Running it multiple times can cause issues. It’s perfect for a one-off emergency repair, but for automation, you need something better. This gets you back online so you can implement the proper fix later.

Solution 2: The Architect’s Choice (The Permanent, Idempotent Fix)

This is how we handle it in our Ansible playbooks and Dockerfiles. It’s clean, declarative, and safe to run over and over again. The logic is the same as the manual fix, but structured for automation. This is the “right” way to do it.

Here’s what it might look like in a `Dockerfile`:

# Set up Docker's official GPG key and repository
# Note: Using non-interactive to prevent prompts in build environments
RUN apt-get update && apt-get install -y ca-certificates curl gnupg lsb-release

# Create the keyrings directory
RUN mkdir -p /etc/apt/keyrings

# Download, de-armor, and store the key in the new standard location
RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Set up the repository source list file with the signed-by directive
RUN echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" > /etc/apt/sources.list.d/docker.list

# Grant read permissions to the key for the package manager
RUN chmod a+r /etc/apt/keyrings/docker.gpg

# Finally, update the package list
RUN apt-get update

Notice we’re using `/etc/apt/keyrings` here, which is the newer preferred location over `/usr/share/keyrings` for keys managed by the local system administrator. This approach ensures your builds are repeatable and follow best practices.

Solution 3: The “Nuke It From Orbit” Option (Do You Even Need This PPA?)

Sometimes the right fix isn’t a fix at all; it’s a removal. Before you jump through hoops to fix a deprecated key warning for a Personal Package Archive (PPA) you added two years ago, ask yourself:

• Is this software now in the official Ubuntu/Debian repositories? Often, a package that once required a PPA eventually gets promoted to the main repos. You might be able to install it with a simple `apt-get install` and remove the PPA entirely.
• Is this project still maintained? If the PPA owner hasn’t updated their instructions to use the new `signed-by` method, it’s a red flag. The project might be abandoned, and you’re holding onto a potential security risk.
• Is there a better way to install this? Maybe the vendor now provides a `.deb` package directly, or a Snap, or a Flatpak, or even a Docker container. The ecosystem evolves.

To find and remove the offending key and source list, you can do some detective work:

# List all the legacy keys
apt-key list

# Find the source file that's causing the problem
grep -r "my-old-ppa" /etc/apt/sources.list.d/

# Once found, delete the key (using the last 8 characters of the fingerprint)
sudo apt-key del FINGERPRINT

# And remove the corresponding .list file
sudo rm /etc/apt/sources.list.d/my-old-ppa.list

# Don't forget to update!
sudo apt-get update

Pro Tip: Don’t just blindly follow old tutorials from 2018. If you’re adding a new repository, always look for the official, up-to-date installation instructions. Any reputable vendor (like Docker, HashiCorp, or Microsoft) will have already updated their docs to use the secure, `signed-by` method.

At the end of the day, this isn’t just about silencing a warning. It’s a fundamental improvement to the security of your Linux systems. Take the time to fix it right once, and you won’t be sweating during a 2 AM deployment like I was.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions