Clira · clearance packet · public sample
A real packet from the live pipeline on a repository with real dependencies. 31 wheels were fetched, the project was built from source offline, and its full 1,953-test suite ran inside the sandbox. Every value below came out of that run. You can recompute the evidence hash and verify the signature yourself.
| Repository | https://github.com/pallets/click |
|---|---|
| Commit | 9c4dfdaebe0e6b2aabc566eb81f6f10eb5cd6ea1 |
| Scanned at | 2026-08-12T19:56:06Z UTC |
| Scope | 159 files · 21,627 lines · {"Python": 18} |
| Findings | 0 — none at any severity |
Installing dependencies means touching the network, and running a project's tests means running its code. Doing both at once is how supply-chain attacks land. So they are separated, and the separation is the whole design:
| Ecosystem | pip |
|---|---|
| Command | pip download --only-binary=:all: --dest /cache/wheels --disable-pip-version-check --no-input flit_core>=3.11,<4 ruff tox tox-uv pytest setuptools wheel flit_core hatchling poetry-core pdm-backend maturin scikit-build-cor… |
| Why it is safe | --only-binary=:all: — wheels are unpacked, never executed. An sdist would run setup.py, which is arbitrary code execution with network access. |
| Result | exit 0 · 31 wheels cached |
| Command | pip install --no-index --find-links /input/wheels --target /work/.clira-site-packages --no-cache-dir --disable-pip-version-check --no-input flit_core>=3.11,<4 ruff tox tox-uv pytest setuptools wheel flit_core hatchling p… |
|---|---|
| What runs here | The project's own build backend compiles click from source. That is customer code executing — deliberately, with no network. |
| Result | exit 0 |
| Framework | pytest |
|---|---|
| Command | python -m pytest -q |
| Result | 1,929 passed · 24 failed · exit 1 · 6.9s |
All 24 are in one file, tests/test_utils/test_echo_via_pager.py, which needs an
interactive pager and a TTY that a sandbox deliberately does not provide. They fail identically on
repeated runs — we checked.
This is the point of a baseline. Clira judges a generated fix by whether it changes this number, not by whether the suite is absolutely green. A patch that leaves it at 24 broke nothing; a patch that makes it 25 is rejected. Reporting a clean 1,953 here would have meant hiding the environment, and then the delta would mean nothing.
| Sandbox image | clira/sandbox@sha256:62f94465b6e07ebc18f40c13553fa9b46ac1cf9c057cb72950bc7a08ce418be1 |
|---|---|
| Runtime | gVisor (runsc) |
| Network (fetch) | enabled, no untrusted code executed |
| Network (build/test) | none |
| Filesystem | read-only rootfs, tmpfs /tmp |
| User | 65534:65534 |
| Toolchain | Python 3.12.3 go version go1.22.2 linux/amd64 v22.23.2 |
The signed verdict carries a SHA-256 of the full evidence document, so the signature binds the commit, the scan, both dependency stages and their exact commands, the test command and its real result, the sandbox image digest and the toolchain versions.
| Evidence SHA-256 | c9d57d8182c5add51f3fc8ad3059f4ad537ceb5948edfcbb9479a2199953aeac |
|---|---|
| Signature | 6rMvEarxa/nZncrYR/YZgUVd+QYYMLEzqjo4qGpbSsCLZ/Baitib7uxS02QlXNdooqCEDfSs2uVwT4G8kWi8AA== |
| Algorithm | ed25519 |
| Public key | 15fMX/qUTOyy/TT+1hW2ZxLHNZjUBEZilt5YRkNvT2E= |
Verify this verdict in your browser Download the evidence document
curl -s https://clira.dev/clearance/pallets-click/evidence.json | sha256sum # => c9d57d8182c5add51f3fc8ad3059f4ad537ceb5948edfcbb9479a2199953aeac
That digest is inside the signed verdict. Change one byte of the evidence and it stops matching; change the verdict and the signature stops verifying. Verification runs entirely in your browser.
It does not say this code is secure. It says: at this commit, our checks found nothing at critical or high severity, and the project's own suite ran to completion in our sandbox with a recorded, reproducible result. Absence of findings is not proof of absence of vulnerabilities.
click had no findings, so no patches were generated. This packet demonstrates the scan, the dependency install and the sandboxed test run — not the repair loop.
Stage A reaches the package registry over unrestricted egress rather than an enumerated per-URL allowlist. That is why it runs no untrusted code at all.