• v0.2.1 c251e4ded4

    mikebrandon released this 2026-09-18 21:09:04 +00:00 | 0 commits to main since this release

    The 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 to Command::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.0 could 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.exe
    

    SHA-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
    from HERE/Capture at 131e5c8 ("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