Dennis HilkLinux Fix LabDE

Package Management & Updates

APT rejects a repository’s signature or trust setup

Missing keys or an unsigned archive can block APT metadata updates. Verify the repository’s signing key and scoped Signed-By configuration.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • APT reports NO_PUBKEY or a repository that is not signed.
  • Only one third-party source fails metadata authentication.

Relevant environment

APT authenticated repositories; legacy GPG diagnostics and newer signature-verifier wording can differ across releases.

Recognizable messages (synthetic examples)
W: GPG error: https://repo.example.invalid stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF

Inspect scoped key configuration and provenance; this does not prove that the repository or a downloaded key is trustworthy.

E: The repository 'https://repo.example.invalid stable Release' is not signed.

Resolve repository trust or disable that optional source; do not mark it universally trusted.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The source may reference a missing, unreadable or wrong Signed-By keyring.
  • The repository may have rotated its signing key or stopped publishing authenticated metadata.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Reads source definitions; missing legacy sources.list is normal with deb822 .sources files. Identify only the failed repository.

rg -n "Signed-By|signed-by|URIs:|Suites:|^deb " /etc/apt/sources.list /etc/apt/sources.list.d

Interpret the result: Compare URI, suite and the exact keyring path. A globally trusted key is not equivalent to a correctly scoped Signed-By source.

Check 2

Replace with the actual Signed-By path; reads metadata without importing keys or contacting keyservers.

stat -c "%A %U:%G %n" /path/to/repository-keyring.gpg

Interpret the result: The file must exist and be readable by APT’s verifier account, commonly _apt. Existence/readability does not establish that its fingerprint is authentic.

Evidence-guided next steps

Install the independently verified repository key in scope

If the publisher documents a legitimate key rotation or missing key, verify its full fingerprint through the publisher’s official channel. Save the old keyring/source, install the authentic key at the documented path and bind only that source to it with Signed-By.

Precautions: Do not fetch an arbitrary matching short key ID and trust it globally. Keep authenticated repository verification enabled.

Recovery / rollback: Restore the saved scoped keyring and source entry if the update was incorrect; an obsolete restored key may remain unable to authenticate newer metadata.

Did this solution help you?

Share this solution#

Disable an optional source that cannot be authenticated

If the repository no longer publishes verifiable metadata, disable only its source entry while investigating with its maintainer. In deb822 use Enabled: no; in a legacy list comment the specific deb line. Keep official distribution sources available for security updates.

Precautions: Do not use trusted=yes, allow-insecure or signature-check bypasses to silence the error. Installed packages from the disabled source may no longer receive updates.

Recovery / rollback: Reenable the saved source entry only after authentic key and metadata publication are confirmed.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.