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 分