Basis CLI

git, public, and never anything else: https://github.com/basis-network/basis-cli

git records the author, the date and the diff of every change. main is protected: no force-push, linear history required, and every change arrives through a pull request whose checks must pass, so the history is a sequence of reviewable steps rather than a series of overwrites.

Work lands on main continuously between releases, through pull requests; the repository is not a drop of release tarballs. Everything since v0.1.0 is visible in the history and in the merged pull requests. https://github.com/basis-network/basis-cli/pulls?q=is%3Apr+is%3Aclosed

git.

Every release has a unique vX.Y.Z identifier, an annotated git tag, and a GitHub release carrying the binaries. The current one is v0.1.0. https://github.com/basis-network/basis-cli/releases

Semantic Versioning. The current release is v0.1.0.

An annotated git tag per release, vX.Y.Z. checksums/<tag>/ is committed before the release is published, so the tag and the checksums it vouches for are one reviewable step. https://github.com/basis-network/basis-cli/tags

CHANGELOG.md, written by hand and not generated from the git log. It says what changed and why it changed: v0.1.0's entry explains that the binaries are not new, only newly versioned, and gives its own section to the removal of basis-node from what this repository vouches for, with the reasoning, because that is the kind of change a user needs to notice. https://github.com/basis-network/basis-cli/blob/main/CHANGELOG.md

There have been no publicly known vulnerabilities in this project's results, so no release has fixed one. The criterion says to choose N/A in exactly that case.

GitHub issues, with templates: one for a bug report, which asks for the version, the platform and the command, and one for documentation. The template chooser also carries a link that sends security reports somewhere else, so nobody files one in public by accident. CONTRIBUTING.md describes what a useful report contains. https://github.com/basis-network/basis-cli/issues/new/choose

GitHub Issues. https://github.com/basis-network/basis-cli/issues

The repository was published on 2026-08-23 and no bug report has been submitted yet, so nothing is outstanding and nothing has gone unanswered. What has arrived — twelve pull requests, eight of them from Dependabot — was reviewed and merged or closed with a reason, all of it within a day. SUPPORT.md states what a reporter can expect, including that nothing outside security reports carries a guarantee. https://github.com/basis-network/basis-cli/issues?q=is%3Aissue

No enhancement request has been submitted yet — the repository has been public since 2026-08-23. SUPPORT.md and CONTRIBUTING.md say what is in scope here and what is not, which is the honest form of an answer given in advance: the CLI's own behaviour is decided in basis-core, and requests about it are forwarded rather than silently dropped.

Every issue and pull request, open or closed, stays public and searchable on GitHub, with each comment addressable by URL. https://github.com/basis-network/basis-cli/issues?q=is%3Aissue

SECURITY.md publishes it: two private routes (a GitHub security advisory, or email to security@basisnetwork.com.co with [security] in the subject), what to include, and the timelines we hold ourselves to — acknowledgement within 3 working days, first assessment within 10, a fix or a stated plan within 90 days of the report. It also says what to do if none of that happens: assume the mail did not arrive and send it again. https://github.com/basis-network/basis-cli/blob/main/SECURITY.md

GitHub's private vulnerability reporting is enabled on the repository, so a reporter can open a private security advisory visible only to them and the maintainers. Email to security@basisnetwork.com.co is the second private route. Neither requires opening anything in public. https://github.com/basis-network/basis-cli/security/advisories/new

No vulnerability has been reported. The repository has only been public since 2026-08-23, well under the six months this criterion asks about.

Nothing in this repository is built. download.sh and the test suite are shell, read by an interpreter exactly as they are committed; the rest is documentation, workflow definitions and checksum files. The basis binary is not built here either — it is downloaded from a GitHub release and verified against a checksum committed to git. The Makefile has check and lint, and deliberately no build, for that reason.

There is nothing to build. (make is present, but only as the entry point for the tests and the linters.)

There is nothing to build. Everything used to check and release this repository is FLOSS anyway: bash, curl, coreutils, shellcheck, reuse, CodeQL and Sigstore cosign.

test/run.sh, Apache-2.0 like the rest of the repository, run with make check. Nine cases, no framework and no network: each one builds a throwaway release under a temporary directory and points download.sh at it over file:// through BASIS_CLI_BASE_URL, and every fixture is made at run time out of strings, so nothing binary is committed.

Two of the cases are the failure paths this repository exists for: a binary that does not match its committed checksum must be refused, and a machine with neither sha256sum nor shasum must refuse rather than skip the check. Both were confirmed to bite — with the verification disabled the suite goes red. How to run it is in the README, in CONTRIBUTING.md and in the CI workflow that runs it on every pull request. https://github.com/basis-network/basis-cli/blob/main/test/run.sh

make check. Shell has no de facto standard test runner, so the Makefile provides the conventional entry point; test/run.sh also runs directly, and make lint is its counterpart for shellcheck and reuse. https://github.com/basis-network/basis-cli/blob/main/Makefile

The suite exercises every branch of download.sh that a user can reach: version selection (including that sort -V puts v0.10.0 above v0.2.0, which an alphabetical sort would not), the BASIS_CLI_VERSION override, a missing checksum file and the error listing it prints, all three arms of the sha256sum / shasum / neither decision, the asset-name mapping with and without a file extension, multi-entry checksum files, verification passing and failing, and that the copied checksum file is not left behind. What is not covered is curl's retry path, which needs a server that fails on purpose.

.github/workflows/test.yml runs make check on every push to main and every pull request, alongside shellcheck, reuse lint, a checksum-format check and CodeQL. All five are required status checks on main, so nothing merges without them. https://github.com/basis-network/basis-cli/actions/workflows/test.yml

CONTRIBUTING.md states it under "Tests": a change to what download.sh does comes with a test; a documentation change does not. The reasoning is given rather than asserted — this script exists to refuse a download that does not match the committed checksum, and a refusal that quietly stops working looks exactly like one that works. The pull request template carries it as a checklist item. https://github.com/basis-network/basis-cli/blob/main/CONTRIBUTING.md#tests

The most recent substantial change to download.sh was the move from a cloud storage bucket to GitHub releases, which introduced the versions(), platforms() and newest() helpers and the asset-name mapping. Five of the nine cases in the suite cover exactly that work, and the two failure-path cases cover the verification it has to preserve. The suite arrived with the policy and covers the whole of the script's current behaviour rather than only its newest part, which is the outcome the policy exists to produce. https://github.com/basis-network/basis-cli/blob/main/test/run.sh

It is written down in CONTRIBUTING.md, in the section a contributor reads before opening a pull request, and repeated as a checklist item in the pull request template. https://github.com/basis-network/basis-cli/blob/main/CONTRIBUTING.md#tests

shellcheck runs over download.sh and test/run.sh on every push and every pull request, and make lint runs the same thing locally. Both scripts also run under bash's nearest thing to a safe mode — set -euo pipefail in the script, set -uo pipefail in the suite, which needs to survive a failing case in order to report it. https://github.com/basis-network/basis-cli/blob/main/.github/workflows/lint.yml

There are none to address: shellcheck is clean on both files, and there is not a single # shellcheck disable anywhere in the repository — nothing has been silenced instead of fixed. It is a required status check on main, so a new warning blocks the merge rather than being carried.

shellcheck runs at its default severity, which is the lowest one and therefore reports everything from style upwards, over every script in the repository, with no exclusions and no suppressions. Its optional --enable=all checks were reviewed and not adopted: they are formatting preferences (brace every variable reference, prefer [[ ]] to [ ]) rather than defect detection, and adopting them would mean rewriting working code to a house style it does not use.

The maintainer designed this repository's delivery model around these principles, and the design is visible rather than asserted.

Fail-safe defaults: download.sh refuses to continue if it cannot verify — if there is no checksum file, if there is no tool to hash with, or if the hash does not match — and never falls back to "download it anyway".

Open design: releases are signed with Sigstore in keyless mode, so there is no private key whose secrecy the scheme depends on; the certificate is in the public Rekor transparency log and anyone can check it.

Separation of privilege: the binary travels through a GitHub release and the checksum through git, so replacing one is not enough — that separation is the reason this repository exists and it is written up in the README.

Least privilege: every workflow is permissions: read-all by default, only the release job asks for more (contents: write and id-token: write), and every checkout runs with persist-credentials: false.

Limited attack surface: nothing here reads a keystore, asks for a passphrase or touches key material of any kind, and SECURITY.md says so explicitly.

Economy of mechanism: the whole verification is one shell script that a reader can hold in their head, which is a deliberate choice over anything cleverer.

Psychological acceptability: the four known rough edges of the CLI are documented in the README precisely because a silent wrong answer — a query that returns "balance 0" for a mistyped address length — is the failure a user cannot detect.

The maintainer knows the classes of error that matter for software of this kind and what counters each.

Supply-chain substitution of a published artifact: countered by checking the binary against a SHA-256 that travelled through a different channel, and by Sigstore signatures over the assets.

A checksum served from the same place as the file it describes (CWE-494, download of code without integrity check): countered by never downloading the checksum — download.sh reads it from the working tree, and this is stated in the script's own header as the reason it exists.

Mutable action tags in CI: every action is pinned to a commit SHA, not a tag, because whoever can move a tag can change what runs.

Credential exposure in CI (CWE-522): persist-credentials: false on every checkout, read-only tokens by default, keyless signing so there is no key to steal, and GitHub secret scanning with push protection enabled.

Expression injection in workflows (CWE-78 in a CI context): CodeQL's actions queries run on every push and pull request, and are a required check.

Unquoted shell expansion and word splitting (CWE-88): shellcheck on every script, required, with nothing suppressed.

For the CLI itself, the network's own design counters the class that matters most for a signing tool: keys are ML-DSA-65 (FIPS 204), the keystore is encrypted, and the passphrase is never transmitted or recoverable.