Package signature checks split into metadata trust and payload trust
Package signature checks split into metadata trust and payload trust A signed package can arrive through a repository whose index was not authenticated. An authenticated repository index can point to a package whose lo
Package signature checks split into metadata trust and payload trust
A signed package can arrive through a repository whose index was not authenticated. An authenticated repository index can point to a package whose local signature policy is weak. APT and RPM expose different parts of this chain, and a review that treats "the key is installed" as the whole control will miss the gap between them.
APT authenticates repository metadata through the Release file and its signatures. The repository publishes a Release file, and the package indexes are covered by hashes in that release. The signed-by option narrows which keys can authenticate a particular source. A source marked trusted=yes is allowed to bypass authentication. Valid-Until and related date checks prevent a stale release from looking current.
The RPM package format carries OpenPGP signatures and digests over the package header and payload. The rpm --checksig operation checks the digests and signatures in a package file to establish integrity and origin. That statement is about the package object. It does not, by itself, prove that the repository client used a signed index, that the client selected the intended repository, or that the signing key belongs only to that repository.
Review both layers
Start with the repository configuration. For APT, list every source, the keyring or fingerprint pinned with signed-by, the suites and components, and any trusted override. Confirm that trusted=yes appears only for a local source with a documented reason. Confirm that the keyring file is readable by the package manager and not writable by an unprivileged application account.
For RPM, identify the keys used to verify packages and the package-manager path that applies them. Check how repository metadata is authenticated in the actual client version and configuration. A key installed in a global keyring may be usable for more repositories than intended. Prefer repository-specific trust where the client supports it.
Then test the failure path. Serve a package with a valid signature from the wrong repository, a package with a corrupted payload, and a stale repository index. If any case installs successfully, the chain has a gap. A zero exit code from a signature inspection tool is not a substitute for an end-to-end install test.
Keep key lifecycle separate from release approval
Expiring a signing key and revoking a package are different actions. Record the key identifier, algorithm, validity window, and revocation state for every release channel. A rotation needs an overlap plan so old and new clients can verify a transition. A revoked key should not remain able to authenticate a new index through an untracked mirror.
Mirrors create another boundary. A mirror can serve bytes, but it should not decide trust. Compare the metadata signature and the package verification against the configured trust anchors. Log the repository identifier, metadata timestamp, package name, version, key identifier, and verification result. Do not log private-key material or full authentication headers.
When a package fails verification, stop that installation path. Do not fall back to an unauthenticated source or an ignored error. The fallback is usually where the useful control disappears.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.