The OpenSSL dependency test fails on a cold cargo cache, leaving CI red on main #269

This was generated by AI during triage.

What happened

CI on main has been red since 362b9ca (run 36863646811), on both test and test-macos, and every pull request into main inherits it. The Runs on #262 and #263 both ended as Failed runs with CI red on test-macos, test, which also fails on main at 362b9ca; fix main first (PRs #267 and #268).

The failing test is the_binary_never_links_openssl:

thread 'the_binary_never_links_openssl' panicked at tests/packaging.rs:79:5:
stderr: error: failed to download `android_system_properties v0.1.6`

Caused by:
  attempting to make an HTTP request, but --offline was specified

Cause (reproduced)

No commit broke it. The test runs cargo tree --target all --offline, which needs the crates for every platform to be in the cargo registry cache already. CI installs floating stable, which moved from 1.98.1 to 1.99.0 between the last green run on main and the red one. The cargo cache key includes the compiler version, so the cache was empty (No cache found), the build downloaded only the crates the runner's own platform needs, and the offline cargo tree could not load the rest.

The failed jobs save no cache, so every run fails the same way until this is fixed.

Reproduced on cargo 1.98.1, so it is the cold cache and not a change in 1.99:

export CARGO_HOME=$(mktemp -d)
cargo fetch --locked --target "$(rustc -vV | sed -n 's/^host: //p')"
cargo tree --edges normal,build --prefix none --format '{p}' --target all --offline   # fails as above
cargo fetch --locked
cargo tree --edges normal,build --prefix none --format '{p}' --target all --offline   # passes

Agent Brief

Category: bug
Summary: The test that keeps OpenSSL out of the binary's dependencies must pass on a cargo cache that holds only the host platform's crates.

Current behavior:
the_binary_never_links_openssl asks cargo tree for the normal and build dependencies on all targets, offline. Offline, cargo can only answer if every one of those crates has been downloaded, including the ones for platforms the machine never builds for. On a fresh cargo cache (a new CI cache key, a new contributor's machine after a plain cargo test) the command fails and the test panics on its status.success() assertion.

Desired behavior:
The test passes wherever cargo test itself can run, whatever is or is not in the registry cache, and still makes no network request of its own. It keeps guarding what ADR 0003 asks for: no openssl-sys, openssl or native-tls among the binary's normal or build dependencies on any target.

How is the agent's choice. Two candidates: read the lockfile, which names every package for every target without touching the registry (it also covers dev-dependencies, which makes the check stricter; say so in the test if that route is taken), or have CI fetch every target's crates before the tests run. The second leaves the test failing on a contributor's cold cache, so prefer a fix in the test unless there is a reason not to.

Key interfaces:

• the_binary_never_links_openssl in the packaging tests: what it reads to learn the dependency set.
• The CI workflow's test jobs, only if the fix needs a step there.

Acceptance criteria:

• With an empty CARGO_HOME that has had only cargo fetch --locked --target <host> run in it, the packaging tests pass.
• The test makes no network request.
• Adding a dependency that brings in openssl-sys, openssl or native-tls as a normal or build dependency, on any target, fails the test (check by hand or by a unit test of the matching; do not commit such a dependency).
• test and test-macos are green on the pull request, from a cold cache.

Out of scope:

• Pinning the Rust toolchain (Pin the Rust toolchain so a new compiler arrives as a pull request #270).
• Changing what the cache action saves or when.
• The other packaging tests.