Mastering APT Source Configuration: Resolving “Signed-By” Ignorance for Secure Package Installation

We understand the frustration when your Advanced Packaging Tool (APT), the cornerstone of Debian-based system management, appears to be selectively ignoring crucial security configurations like the Signed-By directive. This oversight can lead to a critical inability to verify package authenticity, manifesting in errors such as The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [key_id]. At revWhiteShadow, a personal blog site dedicated to providing in-depth technical insights, we’ve meticulously analyzed this common predicament, especially when integrating third-party repositories like the one for AviSynth+ from yuuki-deb.x86.men. Our aim is to provide a comprehensive, actionable guide that not only explains the underlying causes but also offers definitive solutions to ensure APT respects your Signed-By directives and maintains the integrity of your software sources.

This guide will delve deep into the intricacies of APT’s security mechanisms, focusing specifically on how the Signed-By field in .sources files is intended to function and why it might be failing. We will meticulously dissect the provided configuration and error messages to pinpoint the exact cause of the malfunction, empowering you to rectify the situation and securely install your desired packages, such as the latest versions of AviSynth+. Our goal is to equip you with the knowledge to not only fix this immediate issue but also to confidently manage APT repository security moving forward, reinforcing your system’s robustness and trustworthiness.

Understanding APT’s Repository Security and the `Signed-By` Directive

The security of a Linux distribution hinges on its ability to trust the sources from which it retrieves software. APT employs a sophisticated public-key cryptography system to achieve this trust. When you add a third-party repository, it’s essential that APT can verify the digital signatures of the package lists and metadata provided by that repository. This verification process ensures that the packages you download haven’t been tampered with and originate from the legitimate provider.

The Signed-By directive, introduced in newer APT versions (primarily with .sources files), offers a more granular and secure way to manage repository keys compared to the older method of placing keys in /etc/apt/trusted.gpg.d/. Instead of trusting all keys in the global keyring, Signed-By explicitly links a specific repository entry in a .sources file to one or more specific public keys stored in designated keyring files. This isolation enhances security by preventing a compromise of one repository’s key from affecting the trust assessment of other repositories.

A typical .sources file entry using Signed-By looks like this:

Types: deb
URIs: http://example.com/debian
Suites: stable
Components: main contrib non-free
Signed-By: /usr/share/keyrings/example-repo.gpg
Enabled: yes

In this example, APT is instructed to use only the public key(s) found within /usr/share/keyrings/example-repo.gpg to verify signatures for packages from http://example.com/debian. The gpg --show-keys /usr/share/keyrings/example-repo.gpg command is used to list the keys contained within that keyring file.

The `NO_PUBKEY` Error: A Clear Indication of Trust Failure

The error message The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1F331533ABCDEEA3 is a direct consequence of APT failing to find the necessary public key to validate the repository’s release file. When Signed-By is correctly implemented, APT looks for the specified key(s) in the designated file. If the key is not present in that file, or if the file itself cannot be accessed or parsed correctly, APT cannot perform the crucial signature check and flags the repository as untrusted.

The 1F331533ABCDEEA3 part of the error message is the short key ID of the public key that APT expected to find. In the provided example, the gpg --show-keys /usr/share/keyrings/yuuki-deb.gpg output clearly shows this key’s ID: A9BBA31152359AE080A1DF851F331533ABCDEEA3. The fact that APT is reporting NO_PUBKEY 1F331533ABCDEEA3 suggests a mismatch or an inability to access this specific key within the context of the Signed-By directive.

Diagnosing the `Signed-By` Misconfiguration: A Step-by-Step Approach

Based on the information provided, we need to meticulously diagnose why APT is seemingly ignoring the Signed-By directive for the yuuki-deb.x86.men repository. The provided details offer several clues, and we will approach this systematically to identify the root cause.

1. Verifying the .sources File Syntax and Path:

The first step is to confirm that the .sources file itself is correctly formatted and located.

File Path: The file is located at /etc/apt/sources.list.d/yuuki-deb.sources. This is the standard and correct location for custom repository definitions.
Content:
```
Types: deb
URIs: http://yuuki-deb.x86.men/
Suites: bullseye
Components: main
Signed-By: /usr/share/keyrings/yuuki-deb.gpg
Enabled: yes
```
The syntax appears to be correct for a .sources file. Each directive is on a new line, and the values are correctly assigned. The Signed-By directive correctly points to a file path.

2. Inspecting the Keyring File and its Contents:

The Signed-By directive points to /usr/share/keyrings/yuuki-deb.gpg. Let’s re-examine the provided information about this file.

File Existence and Permissions:
```
$ ls -l /usr/share/keyrings/yuuki-deb.gpg
-rw-r--r-- 1 root root 433 Sep 7 20:23 /usr/share/keyrings/yuuki-deb.gpg
```
This shows the file exists and has appropriate read permissions for the root user, which is necessary for APT to access it. The ownership is also correct (root root).
Key Verification:
```
$ gpg --show-keys /usr/share/keyrings/yuuki-deb.gpg
pub   ed25519 2020-03-03 [SCA]
      A9BBA31152359AE080A1DF851F331533ABCDEEA3
uid                      AviSynth+ Yuuki Debian Repository <repo@yuuki-deb.x86.men>
```
This command confirms that the file does contain a valid GPG key, and it identifies the key’s fingerprint (starting with A9BBA31152359AE080A1DF851F331533ABCDEEA3). The error message NO_PUBKEY 1F331533ABCDEEA3 uses the short key ID, which is the last 8 hexadecimal characters of the fingerprint: ABCDEEA3. This confirms that the key listed in the keyring is indeed the one APT is expecting, but it’s not being successfully recognized by APT for verification.

3. Analyzing the apt update Output:

The critical part of the diagnostic is the apt update output:

Err:4 http://yuuki-deb.x86.men bullseye InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1F331533ABCDEEA3

This output confirms that APT is attempting to verify the InRelease file from the repository. The InRelease file is a signed metadata file containing checksums and information about the repository’s packages. APT needs the corresponding public key to verify its signature. The error explicitly states that the public key is not available, despite it being present in the file specified by Signed-By.

Potential Discrepancies and Misinterpretations:

Given that the .sources file syntax, file permissions, and the presence of the correct key in the specified file all appear to be in order, we must consider more subtle issues:

APT Version Compatibility: While .sources files and the Signed-By directive are standard, older versions of APT might have had quirks or incomplete support for certain aspects of this new syntax, especially when dealing with specific key types or keyring formats. However, this is less likely to be the primary issue with modern Debian/Ubuntu systems.
Keyring Format Mismatch: The gpg --show-keys command displays the key in a human-readable format. APT internally uses these keys. It’s possible, though unlikely, that the keyring file is not in a format that APT can directly parse or that the file contains more than just the single public key in a way that confuses APT’s parsing of the Signed-By directive.
Intermediate Proxy or Network Interference: Although less common, network intermediaries or proxies could potentially interfere with how APT fetches or caches repository metadata, though this usually results in connection errors rather than specific NO_PUBKEY errors unless they are corrupting the signatures themselves.
The “Ignoring Signed-By” Symptom: The phrase “seems to be ignoring Signed-By” is our interpretation of APT’s behavior. The reality is that APT is likely trying to use Signed-By but is failing to find or utilize the key as intended, leading to the NO_PUBKEY error. The directive itself isn’t being willfully ignored; rather, the process it governs is failing.

The Definitive Solution: Ensuring APT Correctly Leverages `Signed-By`

The most common and effective way to resolve issues where APT appears to ignore Signed-By directives and fails to verify keys is to ensure the key management is precise and adheres to APT’s expectations. This often involves a slight adjustment in how the key is prepared or referenced, ensuring APT can unambiguously identify and use the correct key for the specified repository.

The core problem often lies not in the .sources file itself, but in how APT locates and associates the key with the repository. Even if the key is in the file, APT needs to explicitly be told which key(s) in that file apply to which repository. The Signed-By directive is designed for this, but sometimes a more explicit approach resolves ambiguities.

Method 1: Explicitly Pointing `Signed-By` to a Single Key

The Signed-By directive can accept a file path or a path to a directory containing keys, or it can be more specific and point to a particular key within a file. When you have only one key in a file, APT should ideally recognize it. However, if APT is struggling, explicitly referencing the key itself can be beneficial.

The Signed-By directive can be formatted as:

Signed-By: /path/to/keyring.gpg

Or, to be even more explicit about which key within that file:

Signed-By: "gpg:/path/to/keyring.gpg"

However, the most robust method for ensuring APT uses a specific key from a file, especially when dealing with single-key keyrings and the NO_PUBKEY error, is to use the key’s fingerprint or short ID.

Let’s reconsider the Signed-By directive using the key’s short ID (ABCDEEA3):

Signed-By: /usr/share/keyrings/yuuki-deb.gpg.d/A9BBA31152359AE080A1DF851F331533ABCDEEA3.gpg

This approach requires us to extract the specific public key into its own file named after the key ID. This is a common practice to avoid ambiguity.

Step-by-Step Implementation:

Ensure gpg is installed:
```
sudo apt update
sudo apt install gnupg
```

Export the specific public key: We can use gpg --export with the key ID to export the public key. To do this, we first need to import the key into our own keyring so gpg --export can find it by its ID.

First, ensure the key is accessible to gpg. If it’s already in /usr/share/keyrings/yuuki-deb.gpg, it might be treated as a “public” keyring by gpg itself. Let’s try importing it into the user’s or system’s primary keyring to ensure gpg --export can find it by ID.
A safer way is to extract it directly if APT cannot use the gpg file directly. We can list the keys and then export the specific public key.

Let’s assume the key A9BBA31152359AE080A1DF851F331533ABCDEEA3 is the one we need.

# Create a directory for this specific key if it doesn't exist
sudo mkdir -p /usr/share/keyrings/yuuki-deb.gpg.d

Now, we need to export the public key from the existing keyring file (/usr/share/keyrings/yuuki-deb.gpg) and save it into a new file named after the key ID. The gpg --export command requires the key to be in a trusted keyring, or it needs to be specified directly if using --keyid.

A more direct approach to extract the public key into a separate file for Signed-By:

# We need to export the key associated with the fingerprint.
# First, import the key from the file into a temporary keyring
# to make it accessible by its ID for export.
# Note: This import might put it into a user-specific keyring.
# A better approach is to use gpg-suite's specific export functionalities.

# Alternative: Directly process the keyring file if gpg can read it
# The most reliable way is to get the KEYID from the show-keys output
# and then use gpg --export --armor KEYID > /path/to/keyfile.asc
# However, the file /usr/share/keyrings/yuuki-deb.gpg might not be directly
# importable by gpg --import for this purpose easily.

# Let's use the `gpgconf --list-options` and related commands, or a simpler direct export
# if the key is already accessible via gpg's public keyring mechanism.

# A common strategy is to use the key ID from the error message directly.
# Since the error says NO_PUBKEY ABCDEEA3, this is the key APT needs.
# The show-keys output confirms this is part of A9BBA31152359AE080A1DF851F331533ABCDEEA3.

# We will export the public key using its full fingerprint.
# Ensure the key is importable to gpg for export.
# If /usr/share/keyrings/yuuki-deb.gpg is a simple ascii-armored file
# or a binary key file that gpg can parse.
# Let's assume gpg can read /usr/share/keyrings/yuuki-deb.gpg for its keys.

# Attempt to extract the key into a specific file name format.
# We use the KEYID that APT is failing to find.
KEYID="ABCDEEA3" # Short ID from the error message
FULL_KEY_ID="A9BBA31152359AE080A1DF851F331533ABCDEEA3" # Full ID from show-keys

# Try exporting using the full key ID to a new file in a specific directory
# This requires gpg to have access to the key. Let's assume we can import it temporarily.

# If the keyring file is binary and gpg can read it:
# We need to get the KEYID that gpg recognizes.
# The error "NO_PUBKEY 1F331533ABCDEEA3" directly tells us the KEYID.

# The most straightforward way is often to ensure the key is in a standard location
# or to provide the key file in a format APT's Signed-By expects.
# The format Signed-By: /path/to/keyring.gpg is standard.

# If APT is failing with this, it might be a subtle format issue or how it
# interprets multiple keys in a single file when only one is needed.
# Let's try to isolate the key.

# Create a directory for specific key files
KEYRING_DIR="/usr/share/keyrings/yuuki-deb.gpg.d"
mkdir -p "$KEYRING_DIR"

# Export the public key using its full ID into a file named by its ID
# We use the full fingerprint for export to be precise.
gpg --export $FULL_KEY_ID | gpg --dearmor > "$KEYRING_DIR/$FULL_KEY_ID.gpg"

# Verify the exported key file
ls -l "$KEYRING_DIR/$FULL_KEY_ID.gpg"
gpg --show-keys "$KEYRING_DIR/$FULL_KEY_ID.gpg"

Modify the .sources file: Update the Signed-By directive to point to this newly created, specific key file.
Edit /etc/apt/sources.list.d/yuuki-deb.sources:
```
Types: deb
URIs: http://yuuki-deb.x86.men/
Suites: bullseye
Components: main
Signed-By: /usr/share/keyrings/yuuki-deb.gpg.d/A9BBA31152359AE080A1DF851F331533ABCDEEA3.gpg
Enabled: yes
```
Important: Ensure the Signed-By path is exactly as created.
Update APT’s package list: Now, run sudo apt update again.
```
sudo apt update
```
If this resolves the issue, the NO_PUBKEY error should disappear, and the repository should be recognized as trusted.

Method 2: Using APT’s Built-in Key Management with `apt-key` (Legacy but sometimes a workaround)

While the .sources file with Signed-By is the modern and preferred approach, sometimes older systems or specific APT configurations might benefit from ensuring the key is also present in APT’s globally trusted keyring. This is a fallback and less secure than strict Signed-By usage, but can help diagnose or temporarily fix the NO_PUBKEY issue if the Signed-By method has an obscure problem.

Note: apt-key is deprecated. The recommended approach is to use .sources files with Signed-By. However, for troubleshooting, it can reveal if the key itself is recognized by APT in any capacity.

Import the key into the system’s trusted keyring:

sudo apt-key add /usr/share/keyrings/yuuki-deb.gpg

If /usr/share/keyrings/yuuki-deb.gpg is a binary key file, this command might fail. If it’s an ASCII armored file, it should work. If it’s binary, you might need to dearmor it first or use gpg --import.

A more robust way to import if it’s a binary file:

# Import the key from the binary file into APT's trusted keys
# The key might need to be imported into a user keyring first for gpg to parse it
# or directly copied to a location gpg can read.
# Let's ensure we are using the dearmored version if possible.

# If you know it's a binary keyring, you might need to convert it.
# However, the show-keys output implies gpg can read it.
# So, adding it directly should be the intention.
# If it fails, the key itself might be corrupted or not in a compatible binary format.

# A common practice with binary keyrings is to copy them to gpg's private directory
# and then use gpg --import. But apt-key add should handle standard binary keyring files.

# Let's assume the gpg command worked and the key is now in the trusted keyring.
# If it failed, the issue is deeper with the key file format or permissions.

Update APT’s package list:
```
sudo apt update
```
If the NO_PUBKEY error disappears after this, it indicates that APT was not correctly referencing the key through Signed-By, but it could find it when it was in the global trusted keyring. This suggests an issue with how Signed-By was interpreted or how the key was presented to APT via that directive.

Method 3: Re-downloading and Verifying the Key

It’s possible that the key file itself, /usr/share/keyrings/yuuki-deb.gpg, was corrupted during download or transfer. Re-acquiring the key from the source repository’s instructions is a prudent step.

Steps:

Consult the repository’s instructions: Go to the yuuki-deb.x86.men repository’s website or documentation for the correct method to obtain and install their GPG key. They typically provide a command or a direct link to download the .gpg file.

Remove the potentially corrupted key:

sudo rm /usr/share/keyrings/yuuki-deb.gpg

Follow the official instructions to re-download and place the key: For example, if the instructions say:
```
wget -O /usr/share/keyrings/yuuki-deb.gpg https://yuuki-deb.x86.men/KEY.gpg
# Or a specific command to fetch and add the key
```
Ensure you use the exact commands and URLs provided by the repository maintainer.

Verify the new key file:

ls -l /usr/share/keyrings/yuuki-deb.gpg
gpg --show-keys /usr/share/keyrings/yuuki-deb.gpg

Confirm the key details match what’s expected.

Update APT:
```
sudo apt update
```

Method 4: Correctly Formatting `Signed-By` for Binary Keyrings

The Signed-By directive expects to point to a file containing GPG keys. These files can be ASCII-armored (.asc, .gpg containing ASCII) or binary (.gpg containing binary data). The gpg --dearmor command converts ASCII armored keys to binary. The gpg --armor command converts binary keys to ASCII armored.

Your output from gpg --show-keys /usr/share/keyrings/yuuki-deb.gpg implies that gpg can read this file, suggesting it’s either a valid ASCII armored file or a binary key file that gpg recognizes.

If the Signed-By directive is consistently failing, it might be that APT’s internal mechanism for parsing binary keyrings referenced by Signed-By is encountering an issue with this specific file’s format or how gpg represents it internally when accessed via Signed-By.

The recommended way to use Signed-By with binary keyrings:

Ensure the key is in binary format: If you obtained an ASCII armored key (.asc), convert it:
```
gpg --dearmor -o /usr/share/keyrings/yuuki-deb.gpg your_key.asc
```
If you already have a .gpg file, it’s likely binary.
Create a Signed-By entry that points to the binary keyring file: The original entry should ideally work if the file is a standard binary keyring:
```
Signed-By: /usr/share/keyrings/yuuki-deb.gpg
```
If this fails, consider the explicit key file method (Method 1). The Signed-By directive in .sources files is designed to be flexible, but subtle differences in how keyrings are structured or how APT interprets them can lead to issues. Method 1, by isolating the specific key into its own .gpg file, often bypasses these interpretation ambiguities.

Final Check and Verification

After applying any of the above solutions, the definitive test is to run:

sudo apt update

You should no longer see the Err: lines related to http://yuuki-deb.x86.men bullseye InRelease and the NO_PUBKEY error. Instead, you should see lines indicating that APT is fetching package lists from the repository without any signature verification errors.

Once apt update completes successfully, you can proceed to install the desired packages, such as AviSynth+:

sudo apt install avisynthplus

By diligently following these steps, you can ensure that your APT sources are correctly configured, that the Signed-By directive is properly respected, and that your system can securely install packages from trusted third-party repositories like the one provided by yuuki-deb.x86.men. This detailed approach addresses the nuances of APT’s security mechanisms, empowering you to maintain a secure and up-to-date system.

apt seems to be ignoring Signed-By

Mastering APT Source Configuration: Resolving “Signed-By” Ignorance for Secure Package Installation #

Understanding APT’s Repository Security and the Signed-By Directive #

The NO_PUBKEY Error: A Clear Indication of Trust Failure #

Diagnosing the Signed-By Misconfiguration: A Step-by-Step Approach #

The Definitive Solution: Ensuring APT Correctly Leverages Signed-By #

Method 1: Explicitly Pointing Signed-By to a Single Key #

Method 2: Using APT’s Built-in Key Management with apt-key (Legacy but sometimes a workaround) #

Method 3: Re-downloading and Verifying the Key #

Method 4: Correctly Formatting Signed-By for Binary Keyrings #

Final Check and Verification #