Feature request: denylist a version level for specific package

[UmanGarbag]

Context

We run the proxy as the single entry point for all package installs in our company (PyPI, Cargo, npm, apt). Cooldown and artifact scanning are both enabled.

This works well for admission. It does not cover a version that was clean when it was first fetched and becomes vulnerable later.

Current behaviour

Two mechanisms exist today, and neither can express "block this specificversion":

• Cooldown filters by publish age. CooldownConfig.Packages is keyed by package PURL, so a per-package override changes the delay for the whole package, not for one version.
• Artifact scanning can block a specific version, but only runs on a cache miss, the scan happens after the artifact is staged and before it is committed to the cache DB. Once an artifact is cached, later requests are served from storage and never re-scanned.

The practical consequences are:

1. A cached version that later gets a CVE keeps being served until it is manually removed from storage and the DB.
2. Even after eviction, the block surfaces as a 403 on the artifact download. The resolver has already selected that version from the metadata, so the install fails instead of falling back to a different version.

Proposal

A version-level denylist, applied at the same place cooldown already filters metadata responses:

denylist:
  packages:
    - "pkg:pypi/requests@2.31.0"
    - "pkg:cargo/some-crate@1.2.3"

A denied version is omitted from metadata responses, exactly like a version still in cooldown. The resolver then picks another version and the build succeeds.

Thanks you for taking in count !

[abhinavgautam01]

hey @andrew, with #360 merged, the remaining gap for the ecosystems listed here is APT metadata filtering: recognized .deb downloads are blocked, but denied versions remain visible to the resolver.

Would you be open to an opt-in filtered APT repository mode? It would remove denied versions from package indexes, regenerate compressed indexes and release checksums, handle by-hash URLs and cached/offline responses consistently and sign the resulting metadata with an operator-provided key that clients explicitly trust. Upstream signatures cannot remain valid after filtering.

this would leave the current pass-through behavior unchanged by default. Is that approach within scope or would you prefer APT
filtering to remain outside the proxy?

[andrew]

Thanks, and thanks again for #360. The gap you describe is accurate: the download guard blocks the .deb but apt has already picked the version from the index, so the install fails instead of falling back.

That said, I'd rather not go down the filtered-repository path right now. Rewriting Packages files means regenerating every compressed variant, recomputing Release checksums, handling by-hash for both original and rewritten payloads, and re-signing with a key the proxy has to hold and every client has to trust. At that point the proxy stops being a transparent cache and becomes a repository authority, which is a different threat model and a lot of ongoing surface across Debian and Ubuntu layout quirks. For now, operators who need a curated APT repo are better served by putting aptly or reprepro behind the proxy.

The fallback benefit is also smaller for APT than it was for npm/PyPI/Cargo. Those indexes list many versions and clients have no native way to exclude one, so the proxy had to filter. A Debian suite usually carries one version per package, so removing it from the index doesn't produce a graceful fallback anyway. And apt already has a client-side per-version denylist via preferences:

Package: somepkg
Pin: version 1.2.3-1
Pin-Priority: -1

That makes the resolver skip the exact version and pick another candidate where one exists, with upstream signatures intact.

So I'm going to hold off on APT metadata filtering for now, though I'm open to revisiting if the pinning approach turns out not to cover people's setups. In the meantime a docs addition covering the APT limitation and the pinning recipe above would be very welcome, so operators know the recommended setup.