supply-chain: guarddog npm is handed git dependencies it cannot look up; sort package.json as references.rs sorts uv export

[HackingGate]

What happens

uphold supply-chain hands package.json to guarddog npm verify unchanged (src/supply.rs, around line 1597). guarddog looks up every dependency on the npm registry by name. A git dependency is not on the registry, so the lookup returns 404, the guarddog section fails, and the pre-push gate refuses the push.

A private repository hit this when it started consuming a sibling private package from the same org:

"@example-org/wire": "git+ssh://git@github.com/example-org/wire.git#v0.1.0"

The only way to push was --no-verify, which also skips every other pre-push gate.

What already exists for Python

src/supply/references.rs sorts the uv export output before guarddog reads it. Registry requirements go to guarddog. A git source is split off and checked against its remote instead: the commit must match a tag, and the owner must be one the repository declares. Direct URLs are reported rather than silently dropped. package.json gets none of this.

Ask

Apply the same sorting to package.json (and bun.lock where it pins the commit):

• specs of the form git+ssh://, git+https://, github:owner/repo#ref, and owner/repo#ref are taken out of what guarddog reads;
• each one is checked like a uv git source: the ref resolves to a tag on the remote, and the owner is a declared owner;
• anything that is neither a registry spec nor a verifiable git spec is refused with a message that names it.

Done when

• A repository that depends on git+ssh://git@github.com/<declared-owner>/<repo>.git#vX.Y.Z passes supply-chain without --no-verify.
• An undeclared owner, or a ref that is not a tag, is refused with a message that names the dependency.
• A fixture test covers each spec form listed above.