Download
Six binaries, one per system/architecture, published on every release by the repo's CI — nothing done by hand. The links below always point to the latest published version.
| System | Architecture | Download |
|---|---|---|
| Linux | x64 | sg-attest-linux-x64 |
| Linux | arm64 | sg-attest-linux-arm64 |
| macOS | Intel | sg-attest-macos-x64 |
| macOS | Apple Silicon | sg-attest-macos-arm64 |
| Windows | x64 | sg-attest-windows-x64.exe |
| Windows | ARM64 | sg-attest-windows-arm64.exe |
Verify integrity
Every release includes SHA256SUMS.txt with the fingerprint of each binary. Compare it before running the downloaded file:
# Linux / macOS
sha256sum -c SHA256SUMS.txt --ignore-missing
# Windows (PowerShell)
(Get-FileHash .\sg-attest-windows-x64.exe -Algorithm SHA256).HashIt makes sense to use the service's own tool to verify itself: sg-attest attest computes the fingerprint of any file, including this very executable.
"Unknown publisher" warning
These binaries are not digitally signed: on first run, Windows SmartScreen or macOS Gatekeeper will show a warning ("unknown publisher"/"unidentified developer"). This is a declared trade-off, not a hidden flaw — in the meantime, the integrity guarantee is the checksum above, together with the fact that the binary is built publicly by the repo's CI, directly from source you can read.
If you'd rather avoid the warning altogether, npx remains the primary channel and never triggers it (see below).
Usage
Same commands as the npm version — you just run the file directly:
# Linux / macOS: make it executable the first time
chmod +x ./sg-attest-linux-x64
./sg-attest-linux-x64 status
./sg-attest-linux-x64 authorize
./sg-attest-linux-x64 attest ./opera.zip --pdf certificato.pdf
./sg-attest-linux-x64 verify ./opera.zip --hash <sha256>On Windows, the same with .\sg-attest-windows-x64.exe. The API key goes in the IMGAUTH_API_KEY environment variable, never passed as an argument (it would end up in the shell history). Every command accepts --json for use in scripts; exit codes are 0 success, 1 operational error, 2 failed verification.
attest without --pdf only computes the fingerprint and signature (nothing is archived); add --pdf <file> to also generate the signed certificate — only then is the work archived and its /c/<fingerprint> page actually exists.
The full list of commands (verify-cert, cert, anchor, …) is in the repo's README.
When to prefer the binary over npx
- A machine or runner without Node.js — minimal images, distroless containers, environments where installing a runtime is a cost you don't want to pay just to attest a file.
- No network access to a package registry — once downloaded, the binary doesn't contact npm: only the attestation API.
- Faster startup — no dependency resolution on every invocation, unlike
npxwith a cold cache.
npx/npm remain the primary channel, and are what attest-action uses in CI: the binary is an additional channel, not a replacement.
src/cli.js), with no dependencies included beyond the runtime needed to run it: the same fingerprint computed locally, the same HMAC, the same signature, the same Bitcoin anchoring. No shortcut reduces the protections described on the service page.