-
released this
2026-09-18 21:09:04 +00:00 | 0 commits to main since this releaseThe release that exists to answer one question: can an install replace itself?
Nothing shipped changes from
0.2.0. The commits between them are a build tool, a test and
documentation, and that is deliberate — the one link in the update chain that has never run is the
handover, an elevated installer replacing the supervisor's own executable while Windows refuses to
overwrite a running binary. Everything up toCommand::new(installer).arg("/S")has tests; that
line has only ever been read. An identical payload is the right payload for the experiment: if
something breaks, it is the handover and not what was handed over.0.1.0could not have been the other half of this. It was packaged at 19:09 and a forge release
only became readable as a feed at 21:46, so an install of it has nothing it can point at.Signed, and proven before publishing — by
cargo xtask bundle, which now signs what it packages
and then verifies that signature against the key compiled into the binaries it just built:bundle: signed, and accepted by the key this build trusts trusted comment: timestamp:1789765700 file:here capture_0.2.1_x64-setup.exeSHA-256
1e7cd131f4399831df1cc6151ff7ce3b08e7f798d484bd7c51ad407045c1238e
Where this came from. This repository is a distribution point, not the source. The tag above is
where the release was filed; it is not the tree that produced the installer. These bytes were built
fromHERE/Captureat131e5c8("Release 0.2.1, to find out whether an install can replace
itself").That distinction is the point of the signature. Nothing here has to be trusted — not the tag, not
the repository, not the feed that pointed at it.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
Source code (ZIP)