Veritasacta Verify

io.github.tomjwxf由 GitHub 账号 tomjwxf 发布v0.11.1更新于 Oct 25, 2026

Offline receipt verifier. Ed25519 signature verification without contacting any server.

已验证STDIO仅桌面开发者工具安全与监控

概览

AI 生成的概览

离线校验已签名 Acta 回执的工具:用你自行提供的公钥验证 Ed25519 签名,无需联系签发服务。

可以做什么
  • 用外部提供的公钥校验单个 Ed25519 信封、v2 结构化回执、v1 扁平回执及历史网站回执。
  • 校验审计包、链、证明包、上下文包、Gate 记录与受治理运行清单,这些需使用 CLI 而非浏览器引擎。
  • 应用签名覆盖的密钥有效期窗口与选择性披露承诺。
  • 以已验证(退出码 0)、失败(退出码 1)或无法判定(退出码 2)报告结果,并给出对应配置的输出与错误码。
  • 执行自检,将受监控源码哈希与内置完整性承诺比对,并生成本地自签名证明。
适用场景
当你收到已签名回执、审计包或证据文件,希望用通过独立可信渠道获得的公钥自行确认签名,而不是信任签发服务时使用。适合重视离线、可复现核验的审计、合规与证据审查流程。
运行要求
需要本地 Node.js 运行时来安装该 npm 包(README 中为全局安装)。需要回执文件和一个独立获得的 64 位十六进制字符公钥。安装完成后校验可离线进行;安装以及显式请求的 URL 或 JWKS 查询会使用网络。无需账号、代理或签名守护进程。
安装前请注意
有效签名并不证明声明为真、动作覆盖完整、签署方有权限或接收方已接受,签名时间戳也只是签发方断言。退出码 1 不代表被篡改,期望公钥错误也会得到同样结果。不要把随未知回执附带的公钥当作独立信任锚。携带密钥与包内密钥选项会削弱结果的说服力。自检并不认证发布者。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Veritasacta Verify,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

@veritasacta/verify

Check signed records yourself, without contacting the issuing service.

An offline CLI and a shared browser receipt engine. Supply a receipt and a public key obtained through a separate trusted channel, then apply your own trust policy. No account, proxy, signing daemon or onboarding step is required to verify a receipt.

Try the browser sample · Receipt specification · Conformance evidence

Verify an existing receipt

bash
npm install -g @veritasacta/[email protected]verify receipt.json --key YOUR_INDEPENDENTLY_OBTAINED_PUBLIC_KEY

The key is 64 hexadecimal characters. Do not treat a key supplied with an unknown receipt as an independent trust pin. This verification path runs offline once the package is installed; installation and explicitly requested URL/JWKS lookups use the network.

An Acta receipt or audit bundle is never checked with a key taken from the file being checked. A receipt whose signed bytes carry a key (public_key, verification_key, verification_jwk) other than the one you supply fails with key_mismatch, and an envelope whose payload names an issuer_id other than its signature's kid fails with issuer_kid_mismatch. An audit bundle's own verification.signing_keys are used only if you pass --trust-bundle-keys, and a valid result then shows only that the receipts match keys in the same file. Gate records, macro track records, governed receipts, proof packs, context packs, repository evidence, standard files and run manifests carry their own key; checked without --key, the result is undecidable (exit 2). --allow-carried-key accepts it (exit 0) and says the signature proves nothing about who signed; --strict refuses it even then. Key windows apply to the issued_at the signature covers, and disclosures are checked against the commitments the signature covers; a disclosure that cannot be applied is not checked (exit 2).

To try the public example, download this receipt and use its demonstration-only key:

bash
verify current-receipt.json --key ebb8cf3efc78717c50e7c438c0ad5498f8fa4e09607fea1e030ac129b5965225

A valid signature is not proof of claim truth, complete action coverage, signer authority or recipient acceptance. A signed timestamp is an issuer assertion, not an independent timestamp.

Read the outcome correctly

OutcomeMeaningNext step
Verified / exit 0The checks implemented for this profile passedApply identity, authority and reliance policies; read warnings and binding scope
Failed / exit 1A verification check failedCheck the expected key, signature, structure and reported error
Not checked / exit 2The verifier could not decideSupply missing material or use a supported format/algorithm

Exit 1 does not prove tampering. Supplying the wrong expected key can produce the same result. Some legacy JSON error categories use the name tampered for compatibility; it denotes failed verification, not a forensic conclusion. See error codes and the profile-specific output.

Browser and CLI

Both use src/detect.js, src/engines/ed25519-receipt.js and the same canonicalizer. The browser bundle is published in browser/, with a SHA-256 build manifest.

The browser accepts individual Ed25519 envelopes, v2 structured receipts, v1 flat receipts and historical website receipt_version: "1.0" receipts. That historical profile excluded public_key from signing and is explicitly labelled; it is not silently promoted to draft-03 conformance. All browser profiles require an external key. Unsupported formats are not checked, not reported as bad signatures.

Both entry points reject duplicate JSON members before parsing. The browser limits input to 1 MiB and depth 64; the CLI file parser allows 50 MiB and depth 128. Bundles and specialist profiles, including selective disclosure, VOPRF, Knowledge Units, Gate evidence and governed-run manifests, require the CLI. Profile success only establishes the checks named in that output, not universal completeness.

Choose a guide

TaskGuide
Verify bundles, chains, prompts or specialist artifactsAdvanced reference
See this CLI's results on TRACE's Acta fixturesTRACE fixture results
Issue receipts or configure a proxy/daemonIssuance and adapters
Understand threats and limitationsThreat model
Report a vulnerabilitySecurity policy
Inspect exact release changesChangelog
Run the tests or contribute a fixtureContributing
Understand project decisions and stewardshipGovernance

Release integrity, not publisher authentication

verify --self-check recomputes monitored source hashes against a bundled integrity commitment (the Sigil). It detects drift from that commitment. Someone replacing both the code and commitment can create a new internally consistent package.

It does not independently authenticate the publisher or establish a canonical release. Pin a reference obtained independently and inspect release provenance. --attest is a local, self-signed integrity statement; separately pin its key before relying on it.

Release and standards status

Verifier: 0.11.1. Status reviewed 2026-10-25.

Internet-Drafts are proposals, not adopted IETF standards or endorsements.

release-manifest.json is the source for version/status blocks in this README, the website, the organisation profile and draft index. node scripts/sync-public-metadata.mjs --check checks sibling repository copies. No draft is revised or resubmitted by this synchronization.

Development and maintainership

Maintained by Tom Farley / ScopeBlind. Independent verification does not imply independent organizational governance. Contributions should include reproducible fixtures and negative cases. The contribution guide covers a clean checkout, package checks and useful first contributions. See the public project evidence for reproducible interoperability results and their limits.

bash
npm cinpm testnpm run check:browsernpm run check:sigilnpm run test:conformance

Apache-2.0. See LICENSE and PATENTS.md for the actual terms. The Acta public record is a separate reference application. ScopeBlind's commercial applications are not prerequisites for verification.

来源:README.md,提交 b5bc8c1

工具

0
SourceWeft 曾在隔离沙箱中以无凭据方式启动该软件包一次,以列出其工具,但未能完成:服务器未能启动。

版本历史

7
  1. v0.11.1最新Oct 25, 2026
  2. v0.11.0Oct 24, 2026
  3. v0.10.27Oct 22, 2026
  4. v0.10.26Oct 20, 2026
  5. v0.10.25Oct 20, 2026
  6. v0.10.23Oct 12, 2026
  7. v0.9.2Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分