DeePloy v0.1.0-rc6

DeePloy 0.1.0-rc6 — packaging: a one-command install that verifies and then
stops, the zim.one/deeploy endpoint as files instead of dashboard clicks, six
docs/ files carved out of a README you can read in one sitting, and four gates
replacing numbers nobody was checking. Deployment logic unchanged since rc3;
not yet run on hardware.

Install

sh -c "$(curl -sSfL https://zim.one/deeploy/v0.1.0-rc6)"

This downloads the release, verifies it against SHA256SUMS, hands the
checkout to root and stops. It does not deploy anything. DeePloy wipes
disks and rewrites GRUB; the command that starts that is one you type
yourself, after reading what you are about to run as root.

Verifying this release

Two checks. They do not prove the same thing, and the difference is the
whole reason both are here.

1. The tarball, against the manifest beside it.

sha256sum -c SHA256SUMS      # must print: OK

Both files were produced by the same workflow run and are served from this
same page, so this catches a download that was corrupted or tampered with
in transit. It says nothing about where the release came from — whoever
could replace one of them could replace the other.

2. The bootstrap, against the digest published here.

get-deeploy.sh is served from zim.one, which is not this page. That
makes this the one check of the two that speaks to provenance rather than
to transport.

curl -sSfL https://zim.one/deeploy/v0.1.0-rc6 | tail -n +2 | sha256sum
# or, without coreutils:  ... | shasum -a 256

must print

cb2bd30bc8e0aacde53c77e7c7efdcc51491dfd692c19e0f63ae2904c1f65f8b

tail -n +2 drops the single line the endpoint prepends to pin the
version. Everything after it is get-deeploy.sh from this tag, byte for
byte — which is what makes "the one-liner and the file you read are the
same file" something you can check rather than something you take on trust.

Tags are annotated but not signed, so a checksum here proves integrity,
not authorship.

Which files the release workflow built

Two: deeploy-v0.1.0-rc6.tar.gz and SHA256SUMS. Those are what the release
workflow builds and what the manifest covers.

The "Source code (zip)" and "Source code (tar.gz)" links below are generated
by GitHub, not by this workflow, and SHA256SUMS says nothing about them.
Download one of those and you will have an archive with no checksum to check
it against — which looks like an unverifiable release and is not one.

Start here

• README
• docs/KEY-MODEL.md —
  what DeePloy does and does not do with your staked key. Read this one first.

Known issue in this release

deeploy.sh ships without its executable bit, so the command this page
and the README print does not work:

$ sudo ./deeploy.sh install --dry-run
bash: ./deeploy.sh: Permission denied

Run it through the shell instead, which behaves identically:

sudo bash ./deeploy.sh install --dry-run
sudo bash ./deeploy.sh install

This reaches further than the first command. The install writes a systemd
unit whose ExecStart= is that same path, to finish the job after the
single reboot; systemd refuses to execute a file without the bit, so the
unit fails 203/EXEC and the post-reboot phase does not run. systemctl enable does not check the bit, so nothing says so before the reboot.
Measured on Ubuntu 24.04: Result: exit-code, status=203/EXEC, and the
same unit succeeds once the bit is set.

Until this is fixed, set the bit yourself before installing:

sudo chmod +x deeploy.sh

Fixed in the next release, together with a gate on every ExecStart= that
points into the checkout and a refusal to write that unit at all when the
target is not executable.

DeePloy v0.1.0-rc5

Draft — see CHANGELOG.md. Verify: sha256sum -c SHA256SUMS