auths pip: verified package installs with signature checking

[bordumb]

Problem

Supply-chain attacks like the recent LiteLLM compromise (malicious versions 1.82.7/1.82.8 pushed to PyPI via stolen credentials) succeed because package managers have no out-of-band signature verification. The attacker had PyPI creds but wouldn't have had the maintainer's device-bound signing keys — if anyone had checked.

Today there's no way to check. pip install trusts PyPI as the sole authority.

Proposal

Ship auths pip install <package> — a thin wrapper around pip that checks the auths public registry for a matching artifact signature before (or after) install.

How it works

auths pip install litellm==1.82.6

1. Resolve the package version from PyPI (same as pip)
2. Query the auths registry: "is there a signature for litellm-1.82.6.tar.gz by a known maintainer identity?"
3. If signed — install proceeds, print verification result
4. If unsigned but previous versions were signed — warn loudly, block by default (--allow-unsigned to override)
5. If no signatures exist for this package at all — install proceeds silently (no adoption penalty)

Key design decisions

• Wraps pip, doesn't fork it. Calls pip install under the hood. We handle verification only.
• Useful before universal adoption. Case 4 above catches the LiteLLM scenario: versions 1.82.0–1.82.6 were signed, 1.82.7 suddenly isn't → red flag. Case 5 means no friction for unsigned packages.
• Signature gap detection is the killer feature. Even partial signing coverage creates a tripwire. An attacker who compromises PyPI creds but not the maintainer's auths identity breaks the signature chain.
• Works with existing auths artifact sign/verify/publish. Maintainers already have the tooling — this is the consumer side.

Stretch: npm and cargo wrappers

Same pattern applies. auths npm install, auths cargo add. Start with pip because the Python ecosystem is the most actively targeted.

Maintainer-side flow (already exists)

# In CI, after building the sdist/wheel:
auths artifact sign --file dist/litellm-1.82.6.tar.gz --device-key-alias ci-publish
auths artifact publish --signature litellm-1.82.6.tar.gz.auths.json --package pypi:litellm@1.82.6

Open questions

• Should auths pip vendor pip or shell out to whatever pip is on PATH?
• Policy file for orgs? e.g. "all packages in requirements.txt MUST be signed" for CI enforcement
• Should the registry return maintainer identity metadata so we can show "signed by did:keri:... (GitHub: @ishaan-jaff)" in the terminal?

Motivation

The LiteLLM attack compromised a PyPI account and pushed infostealer code to 3.4M daily downloads. The attacker had cloud credentials. They wouldn't have had the maintainer's device-bound KERI signing keys. This wrapper turns that gap into a detection mechanism.