Demo: the registry disappeared, and it still builds

A three-minute demonstration of the Software Heritage kill-switch: when a dependency’s upstream registry is gone, Elpe recovers the source from the public Software Heritage archive — cryptographically verified against an intrinsic SWHID — and the build completes.

See doc/operations/software-heritage.md for the design.

What it shows

The recipe build.ml fetches PyPI six 1.16.0 and pins its archived source tree with a SWHID:

swh:1:dir:9a871ce08f925bf939edd7a66500fabdd659889f

fetch_src ?swhid fetches the URL and verifies the bytes against the sha256; on a terminal upstream failure it recovers the tree from the SWH vault and verifies it against the SWHID. So the same recipe builds either way — from the registry when it is alive, from the archive when it is not.

Run it

# daemon on :50051, with SWH_TOKEN in its environment
./demo.sh

• Run 1 (healthy): fetches the real files.pythonhosted.org URL, verifies the sha256, builds.
• Run 2 (kill-switch): DEMO_URL points at a dead host; the upstream fetch fails, and because the entry carries a SWHID the backend recovers the source tree from Software Heritage and the build still completes.

The tell is on the daemon terminal:

kill-switch: upstream dead — recovering swh:1:dir:9a871ce… from the Software Heritage vault
kill-switch: recovered swh:1:dir:9a871ce… from Software Heritage (tree SWHID verified)

The point

Your supply chain does not depend on any single registry staying alive — it is anchored to a public, mirrorable, sovereign archive, and every recovery is verified against an intrinsic identifier (ISO/IEC 18670), not a mirror’s promise.

For a public-software programme this is digital sovereignty you can build: point the fallback at a nationally-hosted SWH mirror and the guarantee holds under any external disruption.

The “under tension” version: torchvision → ffmpeg → CUDA

The sharpest framing for a sovereignty audience is a GPU/vision stack — but the honest punchline is that its three layers are not equally recoverable, and that sorting is the whole argument:

Layer	In Software Heritage?	Kill-switch
torchvision (PyPI, BSD)	✗ wheels-only, PyPI origin not archived	none — nothing to recover
ffmpeg / libavcodec (Ubuntu .deb)	✅ Debian source archived (deb://Debian/packages/ffmpeg)	planned — recover source + rebuild (doc/operations/deb-killswitch.md)
CUDA (nvidia-*-cu12)	✗ proprietary blobs, no source	impossible — SWH archives source, not blobs

• ffmpeg is the good tension (patented codecs, distro stripping) and it is recoverable — because it is open and its Debian source is archived. That is what motivates the deb source-rebuild kill-switch.
• CUDA is the counter-example: the proprietary blob is the one link nobody can archive for you — the reason to prefer open, archivable components. The recoverable set is the open set.

six is used above only because it is a clean, fully-archived source package that makes the mechanism run today; the recoverable AI-stack demo lands once the deb kill-switch (ffmpeg) is wired.

Notes

• The SWHID here was resolved from SWH and is the same value elpe-swhid enrich-lock writes into a real lock’s elpe:swhid property.
• Source-grade, not byte-identical: the recovered tree preserves the files but may nest differently (here the vault yields six-1.16.0/six.py, the sdist yields six.py). The demo’s check is layout-agnostic for that reason.
• For a multi-ecosystem version, enrich a real project’s elpe.lock (npm + pypi + opam + cargo) and dead-host one entry per ecosystem. npm recovery is source-grade (repacked from the archived tree; see the doc).