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.

Everything used here is publicly specified and reviewed: SHA-256 (FIPS 180-4) for the integrity check, TLS for transport — negotiated by curl and by git, not by anything written here — and Sigstore, whose signing certificates are ECDSA P-256 and whose transparency log is public. This repository implements no cryptography of its own; it calls established tools.

It calls sha256sum or shasum from coreutils, curl for transport and cosign for signatures, and re-implements none of them. There is no hand-written cryptographic code anywhere in the repository.

Every algorithm involved has FLOSS implementations, and the implementations actually used are FLOSS: GNU coreutils, curl with OpenSSL or GnuTLS, git, and Sigstore cosign (Apache-2.0).

SHA-256 is a 256-bit hash, above the 224-bit minimum. Sigstore's ECDSA P-256 is a 256-bit curve, above the 224-bit elliptic-curve minimum. TLS is negotiated by curl, which in any current build offers nothing below these minimums. Nothing weaker can be selected here: there is no option to choose a different hash, no --insecure, and no configuration surface at all for the transport.

Nothing here depends on a broken algorithm. There is no MD4, MD5, single DES, RC4 or Dual_EC_DRBG anywhere; the only hash used is SHA-256. There is no cipher-mode choice to get wrong either, because this software encrypts nothing — it verifies and it downloads.

No SHA-1 and no CBC-mode SSH: the only hash is SHA-256 and the only transport is TLS as curl negotiates it. (git names its own objects with SHA-1, which is a property of the version control system rather than of anything this project produces or verifies with — the integrity guarantee this repository makes rests on the SHA-256 in checksums/, not on a commit id.)

This software implements no key agreement protocol of its own, so there is no forward secrecy property for it to have. Transport is curl's TLS, which negotiates ECDHE with GitHub, and that is the whole of the key agreement involved.

Nothing in this repository authenticates external users, so no password is ever stored. download.sh reads no credential of any kind, and SECURITY.md states that nothing here reads a keystore or asks for a passphrase.

Nothing in this repository generates a cryptographic key or a nonce. Key generation belongs to the compiled CLI, which is outside the scope of this entry; the signing done by the release workflow is keyless, so there is no key generated there either.

Three layers, and the middle one is the point. Transport is HTTPS throughout — the repository, the release assets, and every URL download.sh builds. The binary is then checked against a SHA-256 that did not travel with it: the checksum comes from git, where it has a commit, an author, a date and a diff anybody can read, and the script refuses to continue if the two disagree. And every published asset is signed with Sigstore cosign in keyless mode by the release workflow, which verifies it against those same committed checksums before signing; the certificate is in the public Rekor transparency log, and SECURITY.md gives the exact cosign verify-blob command. https://github.com/basis-network/basis-cli/blob/main/SECURITY.md#signatures

The checksum is never downloaded. download.sh reads it from the working tree, which arrived through git over HTTPS, and the script's header says so as the reason it exists: a checksum served next to the file it describes proves nothing, because whoever can replace one can replace the other. There is no code path in this repository that fetches a hash over the network and then trusts it.

There are no known unpatched vulnerabilities of any severity in this project's results. None has been reported or found since the repository was published on 2026-08-23. Dependabot is enabled for GitHub Actions and its alerts are acted on the same day; GitHub secret scanning with push protection is enabled and has flagged nothing.

None has been reported. The commitment is written down in SECURITY.md: acknowledgement within 3 working days, a first assessment within 10, and a fix or a stated plan within 90 days of the report, with the reporter credited in the release notes unless they ask otherwise.

No credential of any kind is in the repository, and nothing here reads one. The release workflow signs with Sigstore in keyless mode, so there is no private signing key that could be committed by accident. Every workflow declares permissions: read-all and only the release job raises it, to contents: write and id-token: write; every actions/checkout runs with persist-credentials: false, so no token is left in the checkout. GitHub secret scanning and push protection are enabled on the repository.

Two tools, both on every push and every pull request, and both required checks on main.

shellcheck analyses download.sh and test/run.sh — it does data-flow analysis well beyond a syntax check, and it is the tool for this language. CodeQL analyses the GitHub Actions workflows (languages: actions), which is the other half of the code here and the half that holds the release credentials: it looks for untrusted input reaching a run step, excessive token permissions, and unpinned or cache-poisonable steps. A workflow is code with credentials, and leaving it unanalysed because it is YAML would miss the most valuable target in the repository. https://github.com/basis-network/basis-cli/blob/main/.github/workflows/codeql.yml

CodeQL's Actions query pack is written for exactly the vulnerabilities of this environment — expression injection, excessive GITHUB_TOKEN permissions, artifact poisoning, unpinned actions. OpenSSF Scorecard also runs against the repository weekly and on every push to main. https://scorecard.dev/viewer/?uri=github.com/basis-network/basis-cli

Neither tool has reported a finding of any severity. Both are required status checks on main, so a finding blocks the merge instead of accumulating in a backlog, and neither has a suppression anywhere in the repository.

Every push to main and every pull request, for both tools, plus CodeQL's weekly scheduled run and Scorecard's.

Nothing in this repository is written in a memory-unsafe language. It is shell, YAML and Markdown. (The CLI it distributes is Rust, and is outside the scope of this entry.)

No dynamic analysis is run, so nothing has been found by it.