A release that proves it installs

[O6lvl4]

v0.5.0 published three assets and looked done. Installing it found three things the workflow could not have known, so the workflow no longer trusts itself.

What installing v0.5.0 found

Half the platforms were missing. Docker on Apple silicon asked the installer for porta-linux-aarch64.tar.gz and got a 404 — as would an Intel Mac, a Graviton instance or a Raspberry Pi. macos-13 and ubuntu-24.04-arm are in the matrix now, so all four are published.

The Linux binary was 552MB. Debug symbols are not something to ask somebody to download in order to run a command. Stripped it is 33MB. The strip happens after the integration suite has run, so what was tested and what ships differ only in symbols.

The verifier checked one half of enforcement. It asserted a write outside every mount was refused — which a binary that runs nothing at all also passes. It checks both halves now.

It also swallowed stderr, so porta correctly refusing a host with no Landlock, in an emulated amd64 container, read exactly like a broken build. That nearly had a working release pulled. The reason is printed now, and an unenforceable host exits 2 by hand but 1 under CI, where the runners are the platforms the release claims.

The pipeline

build   → four platforms; integration suite against the binary it made; strip
publish → as a prerelease, not as latest
verify  → on each of the four, install from the published release over the
          network with the script the README points at, and check it runs,
          refuses a write outside every mount, and writes inside one
promote  → only now is it the release people get

A release that cannot be shown to enforce on one of its own platforms never becomes the one the install instructions hand out.

Also

Bumped to 0.5.1. verify_release.sh is the same check by hand, for a host that is not a runner.

🤖 Generated with Claude Code