install-linux-binary.sh and install-mac.sh were 443 lines that differed
in three places: the OS check and architecture allowlist, the platform
token in the pointer URL and asset name, and clearing the macOS
quarantine attribute. The other ~190 lines were identical.
That duplication already cost something. Hardening the installers meant
applying five fixes twice, by hand, in parallel -- pin-bypass path
traversal, pipeline masking, digest normalisation, directory
destination, and the cross-origin digest check. The next fix would have
had the same shape, and eventually one would land in only one file.
Merge them into install-binary.sh, which detects Linux or macOS and
validates the architecture against what is published for that platform:
Linux ships amd64 and arm64, macOS ships Apple Silicon only.
The release workflow publishes it under the old names as well, so URLs
already in the wild, in the docs, and in the blog post keep working and
pick up the merged behaviour on every release. Nothing needs to change
on the reader's side, and there is no window where a documented command
404s.
Two benign consequences: install-mac.sh now also works on Linux and
install-linux-binary.sh on macOS, and error messages self-identify as
install-binary.sh whichever URL was fetched.
install-linux.sh downloads a native package and registers a systemd
service, which is the wrong shape for deployments that run the server
binary directly -- a hand-run process, a non-systemd supervisor, or a
MinIO deployment being migrated in place.
Add a Linux counterpart to install-mac.sh that fetches only the binary:
resolve the current release from the gh-pages pointer, download the
matching asset, verify its SHA-256, chmod it, and leave ./buckit in the
working directory. It does not touch PATH and does not install a service.
The checksum is verified against both the release-host .sha256sum and the
digest published in the gh-pages pointer, and the two must agree. The
binary and its adjacent checksum share an origin, so that digest alone
only proves the transfer was not corrupted; the pointer is served from a
different origin and turns the check into something an attacker must
defeat in two places. A pinned BUCKIT_VERSION skips the cross-check,
since the pointer only ever describes the latest release.
Publish the script to gh-pages alongside the others, and advertise it in
the README and the generated release-notes install table.
Add install-mac.sh (downloads the Apple Silicon binary, verifies SHA-256,
clears the macOS quarantine attr, prints the move-to-PATH command) and
install-windows.ps1 (downloads the .exe, verifies SHA-256, prints the
move-to-PATH command). Both write to a predictable filename (buckit /
buckit.exe) and use the same atomic temp-then-move + checksum-gate flow as
install-linux.sh.
Publish both to gh-pages in the release workflow, and point install-linux.sh's
non-Linux error at the new scripts.
Add packaging/install-rpm.sh, a POSIX sh helper served from gh-pages that
detects the host package manager (dnf/yum/zypper, apt/apt-get/dpkg, or apk),
downloads the matching .rpm/.deb/.apk for the latest stable release, verifies
its published SHA-256 checksum, and prints the install command to run. It does
not invoke the package manager itself.
Wire the update-gh-pages release job to check out source and publish the
script to pages/install-rpm.sh so it ships at
https://buckit-io.github.io/buckit/install-rpm.sh during a normal release.
- update-gh-pages: remove zip_binary/publish_package/trim_archives; only write
4 buckit.sha256sum files for self-update; generate release/index.html with
per-platform download links and archives/index.html from GitHub API listing
all stable releases; add force_orphan to prevent git history bloat
- gh-pages-index.yml: skip server/buckit/release and server/buckit/archives
so the auto-indexer does not overwrite the custom HTML pages
Binaries exceed GitHub's 100MB git push limit so they cannot be stored
in the gh-pages branch. Two changes to fix this:
- release.yml: stop copying binaries/minisig to gh-pages; write
buckit.sha256sum files with the release tag embedded in the filename
field (e.g. 'buckit.RELEASE.xxx') so the Go code can construct the
versioned GitHub Releases URL.
- update.go / admin-handlers.go: getBinaryURL now constructs a
github.com/releases/download URL when the checksum source is github.io
and the sha256sum filename contains a release tag. Fixes two dead-code
bugs in both admin handlers where 'if updateURL == ""' was always
false after updateURL had already been set.
The previous packaging step used minio/pkger, which is hardcoded for
MinIO's portfolio: its nfpm template only attaches a systemd unit when
the binary name matches "minio", "aistor", or "sidekick". Invoking it
with --appName buckit silently dropped the unit (and the maintainer/
homepage fields stayed MinIO-branded) — the published .rpm/.deb shipped
only /usr/local/bin/buckit with no service definition.
Switch to nfpm directly, driven by a config in packaging/nfpm.yaml that
we own. The packages now contain:
/usr/local/bin/buckit
/lib/systemd/system/buckit.service (Type=notify, LimitNOFILE=1048576,
OOMScoreAdjust=-1000, etc.)
A postinstall script creates the buckit system user/group idempotently;
preremove stops the service; postremove reloads systemd but deliberately
leaves the user in place to avoid orphaning data on attached storage.
The unit is modeled on MinIO's production unit but reads
EnvironmentFile=-/etc/default/minio (leading - = optional), keeping
fresh buckit nodes byte-compatible with the env file MinIO already
ships, so the manager's in-place migration story works without any
config translation.
Verified locally by building rpm/deb/apk against the published
RELEASE.2026-05-11T17-20-40Z binary and inspecting the output.
abuckit