Hashing Dependencies Does Not Make Them Honest

TL;DR: A dependency hash proves which bytes arrived. It does not prove that those bytes will tell the truth after your test runner imports them. The parent slice log records the boundary.

Your lock is pinned. Your wheels match their hashes. Can one of those approved wheels still make the test command say PASS? Yes. That is not a hash failure. It is the limit a hash never claimed to cross.

In this note

• A hash proves identity, not behavior
• Provisioning still earns its place
• The approved wheel that can lie
• Questions for your dependency gate
• Keep the claim small and useful

A hash proves identity, not behavior

A SHA-256 digest answers one exact question: are these the bytes you expected? It cannot answer what those bytes do when executed.

That distinction matters when dependencies participate in a measured command. Ranex materialises the committed subject tree. Ignored environments such as .venv are not part of that tree, so its own bound command, uv run pytest -q, needed a deliberate way to obtain dependencies without trusting an ambient writable environment.

The tempting answer is “hash the wheels.” Hashing is necessary here. It is not independence. A wheel contains executable importable code. In this Python path, pytest loads installed pytest11 entry points before collection. The dependency can therefore influence the exit code the gate later evaluates.

ADR-007 states the boundary directly: dependency code, the resolver, the interpreter, and the environment builder are trusted computing base for that run. Confinement can preserve the selected bytes and deny network access. It cannot turn dependency-selected behavior into an independent fact.

This is not an argument for dropping hashes. It is an argument for refusing to call identity proof a behavior audit.

Provisioning still earns its place

Dependency provisioning reduces hidden change. It makes the run reproducible enough to inspect, rather than accepting whatever happens to be installed.

Ranex separates preparation from measurement. deps fetch is the only networked phase. It resolves a clean copy of the committed manifest with no lock present, under an operator-pinned resolver, Python target, index set, and resolution epoch. The generated lock must byte-match the committed lock. Every selected wheel needs a SHA-256 address; source distributions, local paths, VCS sources, and missing hashes refuse.

The rest follows the same discipline. Store entries are re-hashed when read. The dependency root is assembled from verified entries and made read-only. Approval presents package additions, removals, and version changes, not only opaque digests. The measured command runs offline, with the catalog-bound argv unchanged.

Those controls answer real substitution and drift problems. An authored lock is not accepted as proof of the manifest. A corrupted stored wheel does not quietly load. A new package cannot arrive after approval. If you need to run a dependency-bearing suite against an exact subject, that is valuable work.

For the full operator journey that exposed nine defects around this path, read Nine Defects, Zero Unit Tests. This note stays on the narrower boundary: even a clean, approved, hash-correct dependency remains code that can affect the result.

The approved wheel that can lie

An approved, hash-correct wheel can force a passing verdict. Ranex has an executable limit for exactly that case.

tests/security/test_slice006_approved_wheel_can_lie.py builds an approved wheel with a pytest11 plugin. The wheel passes every integrity control and then forces success. The test is expected to stay green because it proves a declared gap, not a defence.

This is where security language gets expensive. “Verified dependency” can mean the hash matched. It must not be read as “safe dependency,” “trusted publisher,” or “honest test result.” The slice labels import-time execution not caught and preserves a control showing the suite genuinely ran. A green test for an open boundary is not a solved boundary.

Direct imports keep the limit larger than one pytest mechanism. Disabling plugin auto-load would not make other imported dependency code harmless. The dependency is inside the run that produces the evidence.

Questions for your dependency gate

You can use this distinction in any ecosystem. Start by separating bytes, approval, and runtime behavior instead of making one word carry all three.

• Does your resolver derive the lock from controlled inputs, or does it trust a lock the measured party could author?
• Do missing hashes and unsupported sources refuse, or are they treated as convenient exceptions?
• Are resolver, interpreter, indexes, and the artifact store outside the party being measured?
• Can the measured run download, sync, or rewrite its dependency root after approval?
• Does a person see the package delta they approve?
• Which dependency code runs before your test command has collected a test?
• Does your documentation say that a matching hash proves identity, not behavior?

You will not remove the trusted computing base by naming it. You will stop hiding it behind a stronger claim than the evidence supports.

Keep the claim small and useful

Run the strongest dependency process you can justify: clean derivation, pinned inputs, content addressing, readable approval, and an offline measured run. Then state its result precisely.

The result is not “the dependencies are honest.” It is “these approved bytes entered this controlled run.” That is a useful fact. It is also the fact you earned.

Ranex is pre-release. Its dependency provisioning path is built and tested, but it is not a promise that third-party code cannot influence a verdict.

Questions people actually ask

These answers separate artifact identity from the behavior code can take after import.

Does hashing a dependency prove it is safe to run?

No. Ranex treats a SHA-256 hash as proof that approved bytes arrived, not proof that those bytes behave honestly after import.

What does Ranex dependency provisioning check?

Ranex cleanly derives the committed lock under pinned inputs, requires SHA-256-addressed wheels, records an approved package delta, and runs the measured command offline.

Can an approved wheel force a passing test verdict?

Yes. Ranex test_slice006_approved_wheel_can_lie.py demonstrates an approved, hash-correct wheel using a pytest11 plugin to force a passing verdict.

Is Ranex dependency provisioning a finished product feature?

No. The dependency path is built and tested, but Ranex remains pre-release and does not claim a finished product.

Try it. Break it. Tell me what broke.

Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.