When managing software packages on Debian-based systems like Ubuntu, interactions with package repositories are essential. Occasionally, when attempting to update the package list using `apt-get update` after adding a new or third-party repository,

specific errors may arise, indicating issues with cryptographic verification. These errors typically manifest as:

• W: GPG error: #REPOSITORY_URL #DISTRIBUTION InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY #KEY_ID
• E: The repository '#REPOSITORY_URL #DISTRIBUTION InRelease' is not signed.
• N: Updating from such a repository can't be done securely, and is therefore disabled by default.

This situation commonly occurs when the system is configured to use a repository that is not cryptographically signed with a key trusted by the local APT configuration.

Understanding the Repository Signing Mechanism

The Advanced Package Tool (APT) employs GPG (GNU Privacy Guard) keys to ensure the authenticity and integrity of packages downloaded from repositories. Each repository is typically signed with a private key, and the corresponding public key must be present on the system using the repository.

APT uses this public key to verify the signatures of the repository metadata (like `InRelease` or `Release.gpg` files).

If the required public key is missing (NO_PUBKEY) or the repository lacks a signature altogether, APT, by default, refuses to trust it, preventing potentially insecure package operations. The errors signal that this security check has failed.

Read: How to display your sound card details on the terminal on Ubuntu 22.04

Strategies for Resolution

Several approaches can be employed to address these GPG errors, ranging from explicitly trusting the repository to correctly importing the missing keys.

Solution 1: Modify Repository Configuration to Trust

One direct method is to mark the specific repository as trusted within its configuration file. This bypasses the GPG signature check for that entry only.

Repository configurations are typically found in /etc/apt/sources.list or within individual .list files inside the /etc/apt/sources.list.d/ directory.

Edit the relevant file (using a text editor like vim, nano, or a graphical editor) and modify the line corresponding to the problematic repository by adding an option in square brackets.

Option A: Using [trusted=yes]

Add [trusted=yes] immediately after deb:

deb [trusted=yes] #REPOSITORY_URL #DISTRIBUTION #COMPONENTS

For example:

deb [trusted=yes] http://www.deb-multimedia.org jessie main

This option explicitly disables the GPG verification for this repository entry.

Option B: Using [allow-insecure=yes]

Alternatively, use [allow-insecure=yes]:

deb [allow-insecure=yes] #REPOSITORY_URL #DISTRIBUTION #COMPONENTS

For example:

deb [allow-insecure=yes] http://www.deb-multimedia.org jessie main

This flag similarly allows interaction with the repository despite the lack of verification.

Note: Modifying source files usually requires administrative privileges (sudo).

Read: How to Fix’ Symbol grub_calloc Not Found’  GRUB Boot Error

Solution 2: Import the Missing Public Key

The preferred and more secure approach is often to import the repository’s public GPG key. This allows APT to perform the standard verification process.

Method A: Using apt-key adv

If the key ID is known (it’s usually displayed in the NO_PUBKEY error message), it can often be fetched from a public keyserver.

sudo apt-key adv --keyserver #KEYSERVER_ADDRESS --recv-keys #KEY_ID

Using the example key ID 5C808C2B65558117 and a common keyserver like pgp.mit.edu or keyserver.ubuntu.com:

sudo apt-key adv --keyserver pgp.mit.edu --recv-keys 5C808C2B65558117

Consideration: Be aware that the apt-key command is being deprecated. While often still functional, managing keys in /etc/apt/trusted.gpg.d/ is the recommended modern practice, although specific steps for that are not detailed here beyond potential warnings.

Method B: Using gpg and apt-key add

Another way to achieve the same result involves using the gpg command directly to fetch and export the key, then piping it to apt-key add.

gpg --keyserver #KEYSERVER_ADDRESS --recv-key #KEY_ID
gpg -a --export #KEY_ID | sudo apt-key add -

Again, replace #KEYSERVER_ADDRESS and #KEY_ID with appropriate values:

gpg --keyserver pgpkeys.mit.edu --recv-key 5C808C2B65558117
gpg -a --export 5C808C2B65558117 | sudo apt-key add -

Note that newer approach for adding repository keys is to place them in /etc/apt/keyrings/ .

Method C: Manually Installing a Keyring Package

Some repositories provide their GPG keys packaged as a .deb file (e.g., deb-multimedia-keyring). If available, download and install this package.

wget #KEYRING_PACKAGE_URL -O #KEYRING_FILENAME.deb
sudo dpkg -i #KEYRING_FILENAME.deb

For the specific `deb-multimedia.org` example:

wget http://www.deb-multimedia.org/pool/main/d/deb-multimedia-keyring/deb-multimedia-keyring_2012.05.05_all.deb -O deb-multimedia-keyring.deb
sudo dpkg -i deb-multimedia-keyring.deb

This method directly installs the necessary key(s) provided by the repository maintainers.

Read: How to fix Bluetooth connection problems on Ubuntu 22.04

Solution 3: Use Command-Line Flags to Temporarily Allow Unauthenticated Access

For temporary or scripted situations, command-line flags can override the security checks for a single `apt-get` execution. This is generally discouraged for routine use due to security implications.

These flags bypass security safeguards globally for the duration of the command. Using the repository modification methods (Solution 1 or 2) is generally preferred over these global overrides.

In some cases, a combination might be required, for example:

sudo apt-get update --allow-insecure-repositories
sudo apt-get install #package_name --allow-unauthenticated

Solution 4: Scripted Keyring Installation via Temporary Insecure Update

In scenarios where the repository key is *only* available as a package within the repository itself and cannot be obtained externally, a multi-step process might be needed:

1. Ensure the repository is added to your sources (e.g., in /etc/apt/sources.list.d/#your-repo-name.list).
2. Run `apt update` with flags to temporarily allow insecure operations:

   sudo apt -o Acquire::AllowInsecureRepositories=true \
   -o Acquire::AllowDowngradeToInsecureRepositories=true \
   update

   (If this fails due to stale list data, consider removing old list files: sudo rm /var/lib/apt/lists/#your.repo.domain*)

3. Install the repository’s keyring package, allowing unauthenticated sources for this step:

   sudo apt-get -o APT::Get::AllowUnauthenticated=true install #repo-keyring-pkgname

4. Once the keyring package is installed, subsequent `apt-get update` commands should run without GPG errors for this repository.
5. Proceed to install packages from the repository normally:

   sudo apt-get update
   sudo apt-get install #somepkg-from-repo

This approach should only be used when simpler methods like fetching keys from keyservers or secure HTTPS locations are unavailable.

Solution 5: Remove the Problematic Repository Configuration

If the repository causing the error is no longer needed or was added in error, the simplest solution is to remove its configuration file.

First, list the files in the sources directory:

ls /etc/apt/sources.list.d

Identify the file corresponding to the problematic repository (e.g., #problematic-repo.list). Then, remove it using:

sudo rm -i /etc/apt/sources.list.d/#problematic-repo.list

The -i flag prompts for confirmation before removal. After removing the file, run update again:

sudo apt update

The error related to that specific repository should no longer appear.

Verification

After applying one of the solutions, verify its success by running the package list update command again:

sudo apt-get update

If the command completes without the GPG error or “repository is not signed” messages related to the specific repository, the issue has been resolved.

Conclusion

Errors indicating missing public keys (NO_PUBKEY) or unsigned repositories are APT’s default security mechanism to prevent interaction with potentially untrusted sources. Resolving these errors typically involves either correctly importing the repository’s GPG public key, explicitly instructing APT to trust the specific repository via its source configuration, or, less preferably, temporarily bypassing security checks using command-line flags. Choosing the appropriate method depends on the availability of the key and the desired security posture for the system.