feat: private crate registry via JFrog Artifactory (#12)

[BernardJen]

Closes the Cargo half of Lab271/labs-jfrog-poc#12.

Eighteen releases in, publish = false and no crates.io presence meant no colleague could depend on this crate. This wires it to Lab271's Artifactory tenant as a private Cargo registry — opt-in, so a default clone is entirely unaffected.

The public-repo trade-off, and why the config is not committed

Cargo has no per-project registry config that lives outside the working tree. npm has .npmrc, and the JFrog CLI can sidestep even that with jf npm-config. There is no jf cargo-config and no jf cargo command at all — jf --help says so outright. So .cargo/config.toml and CARGO_* env vars are the only mechanisms on offer.

That matters because this repository is public and the Artifactory Cargo index is not anonymously readable:

$ curl -o /dev/null -w '%{http_code}' \
    https://schubergphilis.jfrog.io/artifactory/api/cargo/lab-cargo-dev/index/config.json
401

The index also advertises "auth-required": true, which Cargo honours for crate downloads as well as index reads. A committed source replacement would therefore 401 every anonymous cargo build — every outside contributor, every fork — at dependency-fetch time, with an authentication error that gives the contributor no hint that the fix is to delete a file they did not add.

So: .cargo/config.toml.example is committed, .cargo/config.toml is gitignored. ADR-0038 records the decision and the four alternatives rejected.

package.publish stays false

It does not need to change. cargo package works under it, and the resulting .crate deploys with jf rt upload, which Artifactory indexes into a valid registry entry on its own (~5s later, with deps, features and cksum parsed from Cargo.toml).

publish = ["lab-cargo-dev"] would also work, and is narrower than it looks — cargo publish --registry crates-io still refuses with "The registry crates-io is not listed in the package.publish value", and a bare cargo publish auto-targets the single allowed registry. But it is unnecessary, and only the upload path produces build-info. Whether this crate should be publishable at all is a separate decision and not this PR's to make.

Two things worth knowing before relying on this

• sqlite-rs is already taken on crates.io by an unrelated crate — 19 versions, up to 0.3.7. lab-cargo-dev merges its crates.io cache with our local repo, so one index path serves 20 versions from two different projects with nothing distinguishing them. Ours resolves correctly today only because the version ranges do not overlap. lab-cargo-prod has no remote and serves 0.18.10 alone. Renaming the crate is the real fix, before any public release.
• Consumers should use the named-registry form, not the source replacement. Under source replacement the consumer's Cargo.lock records our private crate as source = "registry+https://github.com/rust-lang/crates.io-index" — untrue, and it makes deny.toml's sources check (unknown-registry = "deny", allow-registry = crates.io only) pass a private-registry dependency silently.

Test plan

Verified against the live tenant, not reasoned about:

cargo fetch --locked through lab-cargo-dev	116 crates resolved, Cargo.lock unchanged — all 116 source entries still point at crates.io
published	lab-cargo-dev-local/crates/sqlite-rs/sqlite-rs-0.18.10.crate, sha256:eb1deeae…
build-info	artifact + 116 deps + commit e04330e8 in one GET /api/build/sqlite-rs/2?project=lab
promoted --copy=true	lab-cargo-prod-local, digest sha256:eb1deeae… — identical, no rebuild
consumed	a throwaway crate declared sqlite-rs = "0.18", resolved 0.18.10 from the registry, compiled and linked it, and ran

Anonymous access was confirmed broken before choosing the mechanism (the 401 above), which is the whole basis for ADR-0038.

Notes for a human

• The jfrog-prod environment does not exist yet. GitHub creates it on this workflow's first run with no protection rules, so the promote job is currently ungated. Add required reviewers under Settings → Environments → jfrog-prod before treating it as an approval gate. Until then the environment records who triggered the run, not who approved it.
• JF_ACCESS_TOKEN is a repo secret carrying project-admin rights on lab, so any workflow in this repository can promote to prod, and one credential covers both build and promote. That is a least-privilege regression against the OIDC design in labs-jfrog-poc#6 and is recorded there, not fixed here.
• Anyone opting in locally needs their own identity token. Nothing in this repository can mint one.
• Verified in CI, not reasoned about. Commits 2 and 4 add and then remove a temporary push trigger for this branch — workflow_dispatch only fires for a workflow that already exists on the default branch, so there was no other way to make the publish and promote jobs actually run. All four jobs went green in run 33790369579 (Promoted bytes identical to dev — no rebuild in the path), and the overwrite guard was verified skipping cleanly in run 33790771562. The trigger is gone from the final state; on: is back to tags and workflow_dispatch.
• Two real defects were found only in CI, both fixed in-branch: Cargo needs [registry] global-credential-providers = ["cargo:token"] named explicitly before CARGO_REGISTRIES_*_TOKEN is consulted at all (not mentioned in Artifactory's Set Me Up), and re-publishing a version silently overwrites released bytes — see the third commit, which is the one worth reading.

Xray

Reported in full in the PoC findings, but the short version, since it bears on this repo's existing supply-chain gate: jf audit does not recognise a Rust project. It reports the tree as [unknown] and generates an SBOM with no library components, so the 116-crate closure that make check-deny and sqlite-rs-dev.cdx.json already cover is never examined. Xray does have Cargo CVE data and applies it to a .crate scanned with jf scan — confirmed against a deliberately vulnerable time 0.1.44, which reports CVE-2020-26235, type cargo — but this crate has zero runtime dependencies, so there is nothing there to find.

make check-deny remains the supply-chain gate. Artifactory adds distribution, not assurance. No change to deny.toml, the SBOMs, or any existing gate is proposed here.

Spend: matched estimate.

🤖 Generated with Claude Code