Skip to content

Track APT warning for trusted HTTPS NVIDIA source #7

Description

@junaga

Problem

The NVIDIA repository is intentionally configured as HTTPS-only trust:

Types: deb
URIs: https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/
Suites: /
Trusted: yes

Trusted: yes tells APT to accept the source even when repository-signature authentication fails. This is deliberate: transport authenticity comes from HTTPS/TLS and the configured CA trust store.

APT 3.3.2 still attempts to verify NVIDIA's InRelease signature and prints:

Warning: Signature verification failed:
Missing key EB693B3035CD5710E231E123A4B469963BF863CC

A clean-cache test proves the source still works: APT downloads the current Release and Packages indexes, exits 0, and uses them. Even apt-get -qq update emits the warning. Hiding stderr would also hide real update failures and is not acceptable.

This appears to be covered by upstream Debian APT bug #1092747, where the newer sqv verification path does not cleanly respect apt-secure overrides.

Repository scope

The CUDA repository is NVIDIA-specific but broader than display drivers: it publishes drivers, CUDA, TensorRT, datacenter/profiling tools, and related infrastructure.

Notably, it also publishes a generic, machine-wide dkms package:

  • NVIDIA: dkms 3.4.1-1, maintained by NVIDIA, section NVIDIA
  • Debian testing: dkms 3.2.2-1, maintained by Debian's DKMS team

Both identify the same upstream project (github.com/dell/dkms), but NVIDIA's package is its own newer build. At equal APT priority, the greater version makes NVIDIA's package the candidate. This is currently accepted, but it means trusting NVIDIA to maintain the system's general kernel-module framework, not only NVIDIA modules.

Done when

  • APT stops emitting a failed-signature warning for a source explicitly marked Trusted: yes, without suppressing unrelated warnings; and
  • after upstream resolution, retest a clean-cache apt update and remove any workaround if one was added;
  • separately revisit whether NVIDIA's generic dkms should remain preferred or be pinned to Debian if it causes compatibility or maintenance problems.

Metadata

Metadata

Assignees

No one assigned

    Labels

    BaseBase platform and system infrastructure

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions