Skip to main content

​
What each release attests

An attestation is a signed record, kept by GitHub, of the workflow and commit that built a file. Every release attests:
  • each command line archive, the macOS app’s zip and the Windows app’s installers, each with a CycloneDX bill of materials (.cdx.json)
  • each Linux package, each with a bill of materials but the keyring’s
  • install.sh, the install script
  • SHA256SUMS, the checksums of the archives, the app’s zip, the installers, the Linux packages and install.sh
  • appcast.xml and appcast-windows.xml, the feeds the apps update from
Only a full release published as the latest carries the feeds. A release candidate, tagged like v1.2.0-rc1, or a beta, tagged like v1.3.0-beta.1, has neither. Checking an attestation needs the GitHub CLI, gh, signed in to a GitHub account.

​
Check an attestation

In the download’s folder, run this with the file’s name:
When a workflow in datlechin/pitboard attested that exact file, gh prints Verification succeeded!. A changed file has no attestation, and the command fails. With --repo alone, gh accepts an attestation from any workflow in the repository. Add --signer-workflow to accept only the release workflow:

​
Check the checksums

Download SHA256SUMS from the same release and check its attestation first:
On its own, SHA256SUMS shows only that a download arrived whole: anyone able to change the release could change a file and its checksum together. Then, in the folder that holds both files, on macOS:
On Linux:
--ignore-missing skips the files you did not download. A file that matches prints:
A file that differs prints FAILED, and the command exits with status 1. On Windows, in PowerShell:
It prints the line of SHA256SUMS for each installer and zip in the folder that matches. A file whose line it does not print differs from the one the release published. Homebrew and the install script check what they install against these checksums, and refuse a download changed on the release page later. apt, dnf and zypper check what they install from Pitboard’s repository against its signatures, as Check the signature says. On Windows, nothing checks an installer or a zip for you.

​
Check the install script

Piped to sh, the script runs unchecked. Its checksums cover the tarball it downloads, not the script. To check the script, download it and check its attestation:
After Verification succeeded!, run the file you checked:

​
Check the signature

The macOS command line and app are signed with a Developer ID and notarised by Apple. On Linux, each RPM package is signed with the repository key, and the other files are not signed. The code signing policy says which Windows files are signed, and from which release.
The app carries its notarisation ticket. Gatekeeper fetches the command line’s ticket from Apple when you first open a copy downloaded in a browser.spctl asks Gatekeeper whether macOS would open a file. For the app:
For the command line, use --type install, since --type execute accepts only apps. In the folder the tarball unpacked into:
Any developer’s notarised file is accepted. With -vvv in place of -v, an origin line names the signer. For Pitboard’s files, it ends with the team identifier (D7HJ5TFYCU).
For what else Pitboard protects against, see SECURITY.md.