Module artifact 

Choosing the one published Linux archive that matches, proving it is the one that was published, and putting the binary inside it at /usr/local/bin/runner-manager without a moment in which that path holds half a file.

There is no download here, and that is the point

crates/app/src/cli/update.rs already fetches release assets, and it does so under two controls worth keeping: the origin is either GitHub or a loopback/local mirror, and SHA256SUMS is checked before anything is installed. Re-implementing the fetch in this crate would mean a second origin policy to keep in step with the first — which is the shape of an unverified download path even when the first version of it is careful.

So this module takes an archive a caller already has plus the checksum document that describes it, and refuses to do anything with the archive until its SHA-256 matches. The orchestration layer supplies both from the existing update path. What is genuinely new here — and could not be borrowed — is everything after the digest matches, because the destination is inside another operating system.

Exact version, not newest

select_exact_release differs from update’s selection in exactly one way, and it is the important one: update looks for the newest published archive, and this looks for the archive whose version is exactly the one asked for. 02-target-architecture.md step 2 requires “the Linux release artifact whose semantic version exactly matches the controlling Windows binary”, because a WSL host running a different build from the Windows host that manages it is a support matrix nobody wants and a bug report nobody can read.

Atomicity is a rename inside the distribution

Windows cannot atomically replace a file that lives in ext4 inside a WSL virtual disk, so the whole install happens there:

1. the archive’s SHA-256 is verified on the Windows side, before a byte of it is piped anywhere;
2. a 0700 staging directory is created beside the destination, so the final step is a rename within one filesystem and is therefore atomic;
3. the archive is streamed into tar on the child’s stdin and the one wanted member is extracted;
4. the extracted binary is made executable and asked its own --version, which must be exactly the version selected;
5. only then is it renamed onto the destination.

Every failure before step 5 leaves the destination exactly as it was — 03-security-and-lifecycle.md’s “old binary remains executable” row — and the staging directory is removed on the way out either way.

Structs

BinaryInstaller

Stages and installs one release binary inside a distribution.

InstalledBinary

What was installed, once the rename succeeded.

LinuxBinaryPath

An absolute Linux path to a file, split into the parts the install needs.

PublishedArtifact

One release artifact: what it is called and what it must hash to.

ReleaseTarget

The published artifact for one operating system and architecture.

Constants

DEFAULT_LINUX_DESTINATION

Where the Linux binary lives, which is what install.sh and the Linux service registration already assume.

MAX_ARCHIVE_BYTES

The largest archive this will pipe into a distribution.

Functions

linux_target

The published Linux archive for an architecture.

parse_semantic_version

X.Y.Z, as three numbers.

read_verified_archive

Reads an archive into memory and returns it only if it is the published one.

select_exact_release

Finds the archive for target whose version is exactly version.

sha256_of_file

The SHA-256 of a file, lower-case hex.

version_of_asset

The version in runner-manager-<X.Y.Z>-<target>.<extension>, when the name is exactly that and nothing else.