Conflicting values set for option Signed-By regarding source

1. Introduction

In Linux, package managers simplify software installation and update processes, and ensure that software sources are verified and trustworthy. However, when dealing with software repositories and their associated security measures, a common stumbling block we might encounter with the sudo apt update command is the error: “E: Conflicting values set for option Signed-By regarding source“.

In this tutorial, we’ll demystify this error and discuss several basic and advanced methods to resolve it. Let’s get started!

2. Understanding the Error

At its core, the “E: Conflicting values set for option Signed-By regarding source” error is a security mechanism in disguise that protects our system from unverified or potentially harmful software:

$ sudo apt update
E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ jammy: /etc/apt/keyrings/docker.gpg != 
E: The list of sources could not be read.

This error occurs when the Advanced Package Tool (apt) detects inconsistencies or conflicts in the GNU Privacy Guard (GPG) keys used to sign the software repositories.

2.1. The Role of GPG Keys in Software Security

For a broader perspective on why these verification tasks matter, let’s briefly discuss the underlying importance of these GPG keys in software security.

First and foremost, GPG keys ensure that the packages we download and install have not been tampered with since their creation. This is crucial for preventing the installation of malware-infested software that can compromise our system.

Also, they verify that the packages come from the claimed source and official repository. This authenticity check prevents man-in-the-middle attacks, a notorious IT attack in which an attacker could impersonate a software repository.

Lastly, GPG keys are part of a trust chain in software ecosystems, connecting end-users to software vendors. By verifying the signatures, we can trust that the software we’re installing is legitimate and safe.

In short, GPG keys are a hallmark of trust, ensuring the software we’re installing has not been tampered with.

2.2. Relating the Error and GPG Keys

When we encounter the error, it’s usually because apt has found multiple conflicting instructions regarding the GPG key to verify a particular repository.

Specifically, this conflict arises from duplicated repository entries, incorrect or outdated GPG keys, or improperly configured repository settings. Each of these issues points to a common theme: the need for meticulous management of software sources and their associated verification keys.

Therefore, resolving this error involves some detective work and system housekeeping.

First, we’ll need to identify the source of the error. Typically, the conflict arises from either duplicate entries in our sources.list files, permission issues with the GPG keys, or outdated information pointing to a repository’s signing key.

Fortunately, addressing this error not only helps restore the functionality of our package manager but also reinforces the security and integrity of our system’s software supply chain.

2.3. Preliminary Steps Before Troubleshooting

Before troubleshooting, let’s ensure that our system meets any prerequisites or compatibility requirements for the software we’re attempting to install. This might seem elementary, but it’s a step that’s often overlooked and can save us a considerable amount of time and effort down the line.

Next, it’s wise to back up any critical data, especially when working on a production system. While the steps we’ll discuss are generally safe, having a backup ensures we can recover quickly from unforeseen complications.

Additionally, quickly reviewing the software repository’s setup instructions can offer insights. Sometimes, the solution is as simple as updating a repository URL or installing a new package version.

However, if the error persists after some troubleshooting, having these preliminary checks out of the way puts us in a better position to tackle the error head-on. Remember, our goal here isn’t just to fix a single issue but to enhance our system’s integrity and reliability.

Notably, for troubleshooting purposes, we’ll use Docker and its repositories as a primary example. This provides a concrete, real-world scenario that many Linux users encounter. However, the principles and steps discussed generally apply to other software repositories and similar errors.

3. Correcting Permissions for GPG Keys

Incorrect permissions on GPG key files can prevent the apt update command from reading or using the necessary keys for repository verification.

Therefore, our first step is to check and correct the permissions with the chmod command using administrative privileges (sudo).

For instance, let’s adjust the permissions for the Docker GPG key:

$ sudo chmod a+r /etc/apt/keyrings/docker.gpg

Here, a+r adjusts the permissions to add (+) read access (r) for all users, and /etc/apt/keyrings/docker.gpg specifies the path to the GPG key that needs permission adjustments.

After making this adjustment, let’s try rerunning the sudo apt update command. If the issue was related to file permissions, this should likely resolve the error.

4. Removing Conflicting Keyrings

If the problem persists after correcting the permissions for the GPG Keys, we may have conflicting keyring files.

Keyring files are crucial for securing apt repository communications on Debian-based systems like Ubuntu. They contain the public GPG keys for the repositories. The system uses these keys to verify the authenticity and integrity of the packages it downloads and installs.

4.1. Locating Conflicting Keyring Files

Conflicting keyring files usually occur when multiple keyrings are present for the same repository, potentially leading to apt’s confusion about which keyring to use for verification.

To locate and identify these keyring files, first, let’s use the ls command to list all keyring files within the /etc/apt/keyrings/ directory:

$ ls /etc/apt/keyrings/
..
docker.asc
docker.gpg
...

For this example, we notice two GPG keyring files related to Docker. This could be the root of the conflict.

4.2. Inspecting sources.list

Next, let’s check the sources list for Docker entries:

$ cat /etc/apt/sources.list.d/docker.list
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu focal stable

Here, let’s confirm that only one Docker entry references one of the keyring files.

To resolve the conflict, we need to decide which keyring file is correct.

However, after looking for guidance on Docker’s website, we learned that docker.asc is the current, valid keyring file, and docker.gpg is outdated or mistakenly added.

Thus, for this scenario, removing this conflicting keyring will most likely clear the error:

$ sudo rm /etc/apt/keyrings/docker.gpg

Notably, let’s be cautious with removal (rm) commands. Aside from this sample scenario, we need to ensure we’re deleting the correct files, as removing essential keyrings or sources can complicate matters further.

Finally, with the removal of the conflicting keyring file, let’s rerun the apt update command to test if this resolves the conflict:

$ sudo apt update
...
Get:1 https://download.docker.com/linux/ubuntu focal InRelease [30 KB]
Get:2 https://download.docker.com/linux/ubuntu focal/stable amd64 Packages [35 B]
Reading package lists... Done

This time, the update process was completed without errors, confirming that removing the conflicting keyring file resolved the issue.

5. Cleaning up sources.list.d

Another common culprit for this error is duplicate or conflicting entries within our sources.list.d directory.

To fix this, first, let’s navigate to the /etc/apt/sources.list.d directory and list all the files to check for potential duplicates:

$ cd /etc/apt/sources.list.d
$ ls -la
total 12
drwxr-xr-x 2 root root 4096 Apr  2 12:00 .
drwxr-xr-x 6 root root 4096 Apr  2 11:59 ..
-rw-r--r-- 1 root root  134 Apr  1 08:00 docker.list

Here, we see the docker.list file.

Let’s inspect and edit the file with a text editor (for example, the vi editor) to ensure no duplicate entries exist inside it:

$ sudo vi docker.list

...
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu focal stable
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu focal stable
...

As we can see, a duplicate entry exists.

To fix this, we need to delete the duplicate or comment it out manually by adding a # at the beginning of the line.

Notably, this file also contains lines specifying different signed-by options for the same repository. We need to choose the correct entry (usually the one with the most recent signing key) and comment out the incorrect ones.

Afterward, we should try our update again and see if the double entries in the source.list file caused the error. If it did, the update should now proceed without issues. Otherwise, our hunt continues.

6. Advanced Troubleshooting

If the standard troubleshooting methods we’ve discussed don’t resolve the “E: Conflicting values set for option Signed-By regarding source” error, it’s time to explore advanced troubleshooting techniques.

In the next few sections, we’ll dive into these methods that address less common but more complex issues that can cause this error.

7. Verifying GPG Keys Manually

If the error persists, we need to manually verify the GPG keys used by our repositories to identify discrepancies. This involves fetching the public key directly from the software source or its official website and comparing it to the one installed on our system.

For instance, as we’ve demonstrated in our previous interactions, let’s assume we’re troubleshooting the persistent error for Docker’s repository on our Ubuntu system. Yet, we’ve applied the standard fixes, which haven’t worked, prompting us to manually verify the GPG key.

Let’s see how to import and verify a new GPG key against our repository.

7.1. Fetching and Installing the Official GPG Key

Software providers, like Docker, typically publish their GPG keys on official websites or documentation. We need to fetch the correct key to ensure the integrity of the packages we’re attempting to install.

To import the GPG key directly into the correct directory, let’s use the curl command with gpg to fetch it and save it in a format that apt recognizes:

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.asc

Here, the curl command downloads Docker’s official GPG key, converts it from armored ASCII format to a binary format (–dearmor), and saves it to /etc/apt/keyrings/docker.asc, making it ready for apt to use.

7.2. Updating the Repository Configuration to Use the New Key

With the new GPG key in place, we need to ensure our repository configuration correctly references this key. This involves specifying the signed-by option with the path to the newly installed key.

Let’s start by editing the repository’s source file to do this.

Specifically, for our sample scenario, i.e., Docker, it’s typically located at /etc/apt/sources.list.d/docker.list:

$ sudo vi /etc/apt/sources.list.d/docker.list

...
deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable
...

Let’s now modify this line to include the signed-by option, pointing to the location of the GPG key we just saved:

# File docker.list

...
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu focal stable
...

Notably, let’s ensure that the path specified in signed-by= exactly matches the location where we’ve confirmed the correct GPG key is stored (in our case, /etc/apt/keyrings/docker.asc, which is accurate).

Afterward, we should save our modifications and exit the editor.

Now, let’s rerun the sudo apt update command to ensure that apt can successfully verify the repository’s packages using the new GPG key.

If we see no GPG errors, that means apt can now successfully recognize the new key and use it to verify the repository.

8. Debugging apt Configurations

If we’re still encountering the error after trying out previous fixes, there could be an issue with how apt is handling the repository’s GPG keys or a network-related issue that’s not immediately apparent.

Fortunately, using apt’s debugging options can provide insights into what’s going wrong during the update process.

To get to the bottom of this, let’s increase the verbosity of apt update to see more detailed output about the HTTP transactions involved for debugging purposes:

$ sudo apt update -o Debug::Acquire::http=true
0% [Working]GET http://download.docker.com/linux/ubuntu/dists/focal/InRelease HTTP/1.1
Host: download.docker.com
...
Reading package lists... Done
E: Failed to fetch http://download.docker.com/linux/ubuntu/dists/focal/InRelease  Something wicked happened resolving 'download.docker.com:http' (-5 - No address associated with hostname)

Here, our debugging output indicates that apt cannot resolve the host or connect to the repository. This might suggest a network configuration issue, a DNS problem, or that the repository is currently unreachable.

Also, let’s check if there’s an issue specifically with the GPG keys:

$ sudo apt update -o Debug::Acquire::http=true
Err:8 http://download.docker.com/linux/ubuntu focal InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9DC858229FC7DD38854AE2D88D81803C0EBFCD88
Reading package lists... Done
W: GPG error: http://download.docker.com/linux/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9DC858229FC7DD38854AE2D88D81803C0EBFCD88

Here, apt shows missing public keys (NO_PUBKEY) or issues verifying signatures, indicating a problem with the GPG keys configured for the repository.

Generally, for network-related issues, we should cross-check our internet connection and DNS settings and ensure that the repository URL is correct and reachable.

On the other hand, for GPG key issues, we might need to import the missing GPG key using the methods we discussed earlier or check that the signed-by option in our repository configuration points to the correct keyring file.

9. Reconstructing the sources.list File and Keyrings

Suppose that after extensive troubleshooting with previous steps, we’re still encountering the error, or generally experiencing issues with apt repository conflicts or GPG key errors. As a last resort, we may need to reconstruct our sources list and keyrings from scratch. This is a drastic measure that we need to approach with caution.

9.1. Backing up Current Configuration

Let’s start by backing up our current sources.list file and keyrings:

$ sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup
$ sudo cp -r /etc/apt/sources.list.d /etc/apt/sources.list.d.backup

Next, we should clear the existing sources.list after backing it up:

$ sudo echo "" > /etc/apt/sources.list

Afterward, we should carefully rebuild our sources.list file only with repositories we trust and need.

For instance, for Ubuntu 20.04 (Focal Fossa), we might want to add the main and universe repositories:

$ echo "deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list
$ echo "deb http://archive.ubuntu.com/ubuntu/ focal-updates main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list
$ echo "deb http://archive.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list

If we’re using other distributions or versions, we need to adjust these commands as necessary. The official repository lines are generally available on the distribution’s website or help pages.

9.2. Rebuilding the /etc/apt/sources.list.d/ Directory

Next, we should remove all current files (after backup):

$ sudo rm /etc/apt/sources.list.d/*

Then, we can also populate our /etc/apt/sources.list.d directory and re-add the repositories we need, one by one, ensuring they are from trusted sources.

9.3. Re-Importing the GPG Keys

It’s important that we only import the GPG keys necessary for the repositories we trust and have added back.

We’ll typically find instructions for each repository on the official website for importing their GPG key.

For example, let’s download the key for Docker:

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.asc

When we’re done carefully re-adding our repositories and their corresponding GPG keys, let’s now update our package lists and upgrade our system to reflect these changes:

$ sudo apt update
$ sudo apt upgrade

This process should set the stage anew for our system’s package management, clearing out any misconfigurations or conflicts causing issues.

10. Conclusion

In this article, we looked into understanding and resolving the “E: Conflicting values set for option Signed-By regarding source” error in Linux.

We started with the critical role of GPG keys in software source verification. Then, we discussed more advanced techniques involving manual key verification and apt debugging.

Finally, we should remember the importance of diligent repository and keyring management, as it cannot be overstated. It underpins the entire security and stability of our Linux environment.