Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CarlosEduJs/SCAL-P/llms.txt

Use this file to discover all available pages before exploring further.

SCAL-P spends its runtime verifying npm and pnpm packages before they are installed. Binary verification closes the loop: the same SHA-512 hashing engine and audit infrastructure that protects your dependencies also protects the SCAL-P binary itself. If you cannot verify the tool that does the verifying, you have a trust problem. This guide covers how release authors generate checksums and how users verify downloads before running them.

​
Why binary verification matters

SCAL-P’s value proposition is “verify before trust.” Distributing a binary without a verification path would undermine that claim entirely. The scalp checksum and scalp verify commands use the same hash format (sha512-<base64>), the same audit log (.scalp/audit.log), and the same policy enforcement model as every other SCAL-P command — no special cases for SCAL-P itself.
Binary verification does not replace transport security or GPG signing. Download the binary and checksums file over HTTPS. Consider GPG-signing the checksums file as an additional layer. See limitations for what this feature does not cover.

​
Commands

Two commands form the release verification chain: scalp checksum — run by the release author to generate a checksums file: 
scalp checksum [--output <file>] <files...>
  • Reads each file, computes its SHA-512, and writes one line per file
  • --output writes to a file; without it, output goes to stdout
  • No policy, no audit, no enforcement — it is a pure hash utility
scalp verify — run by the user after downloading a release artifact: 
scalp verify --artifact <file> --checksum <file> [--policy <file>] [--ci]
FlagDefaultDescription
--artifactrequiredPath to the downloaded release artifact
--checksumrequiredPath to the checksums file
--policy.scalp/policy.jsonPolicy file controlling enforcement behavior
--cifalseOverride enforcement to block regardless of policy

​
Verification flow

1

Release author: build and package artifacts

Build your release binaries. For SCAL-P itself, GoReleaser produces .tar.gz and .zip archives for each target platform.
2

Release author: generate checksums

Run scalp checksum against all release artifacts. The output is a plain-text file with one sha512-<hash> <filename> line per artifact:
scalp checksum scalp_linux_amd64.tar.gz scalp_darwin_amd64.tar.gz > checksums.txt
Output format:
sha512-a1b2c3d4...  scalp_linux_amd64.tar.gz
sha512-e5f6g7h8...  scalp_darwin_amd64.tar.gz
3

Release author: upload artifacts and checksums

Upload the binaries and the checksums.txt file together. Users must be able to download both. The checksums file is useless without the artifact and vice versa.
4

User: download artifact and checksums

Download the release artifact for your platform and the checksums.txt file from the same release. Use HTTPS.
5

User: run scalp verify

Run scalp verify with both files. Pass --ci to force blocking enforcement regardless of local policy:
scalp verify \
  --artifact scalp_linux_amd64.tar.gz \
  --checksum checksums.txt \
  --ci
scalp verify loads the policy (or defaults), parses the checksums file, looks up the artifact filename, computes its SHA-512, compares against the stored hash, logs an audit event, and enforces the result.
6

Check the audit log

Every scalp verify invocation appends one event to .scalp/audit.log. Inspect it to confirm the verification ran and what the outcome was:
{"ts":"2026-05-13T12:00:00Z","event":"binary_verify","pkg":"scalp_linux_amd64.tar.gz","status":"verified","hash_match":true}
status is "verified" on a match and "mismatch" on failure.

​
Release pipeline and user verification examples

# Generate checksums during release
- name: Generate checksums with scalp
  run: |
    /tmp/scalp-bootstrap checksum dist/*.tar.gz dist/*.zip > dist/checksums.txt

# Verify all artifacts with scalp (dogfooding)
- name: Verify all artifacts with scalp
  run: |
    for f in dist/*.tar.gz dist/*.zip; do
      echo "Verifying $(basename $f)..."
      /tmp/scalp-bootstrap verify --artifact "$f" --checksum dist/checksums.txt --ci
    done

# Upload artifacts and checksums to the release
- name: Upload scalp checksums to release
  run: gh release upload "${{ github.ref_name }}" dist/checksums.txt --clobber
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

​
Enforcement behavior

Without --ci, enforcement is controlled by your .scalp/policy.json. The default enforcement level when no policy is present is warn.
EnforcementHash matchHash mismatch
warn (default)exit 0Logged, exit 0
blockexit 0exit 1
logexit 0Silent, exit 0
With --ci, enforcement is forced to block regardless of the policy file. Use --ci in automated pipelines where a mismatch must halt execution.
The default enforcement of warn means a hash mismatch will be logged but will not stop execution unless you pass --ci or configure block in your policy. Always use --ci in release validation pipelines.

​
Audit event

Every scalp verify call produces exactly one audit event appended to .scalp/audit.log: 
{"ts":"2026-05-13T12:00:00Z","event":"binary_verify","pkg":"scalp_linux_amd64.tar.gz","status":"verified","hash_match":true}
FieldValuesDescription
event"binary_verify"Event type
pkgfilenameThe artifact that was verified
status"verified" / "mismatch"Outcome of the hash comparison
hash_matchtrue / falseWhether the computed hash matched the checksums file
The event appears in the same log as all other SCAL-P events (install, audit, policy_violation). There are no special-case log files for binary verification.

​
Limitations

Binary verification with scalp verify does the following and nothing more:
  • Computes SHA-512 of the artifact
  • Compares against the stored hash in the checksums file
  • Logs the result to .scalp/audit.log
  • Enforces based on policy or --ci
It does not:
  • GPG-sign or verify the checksums file — do that separately with your signing key
  • Verify the checksums file’s own authenticity — HTTPS delivery and GPG signing are your responsibility
  • Scan the binary for malware — that is your OS vendor’s domain
  • Accept wildcards in --artifact — verify one file at a time

Build docs developers (and LLMs) love

Get started for freeTalk to us