norcaster-verify 0.4.0__tar.gz

norcaster_verify-0.4.0/.gitignore

@@ -0,0 +1,7 @@
+dist/
+__pycache__/
+*.egg-info/
+node_modules/
+.venv/
+*.pyc
+.pytest_cache/

norcaster_verify-0.4.0/CHANGELOG.md

@@ -0,0 +1,83 @@
+# Changelog
+
+Versions apply to both packages, `norcaster-verify` (PyPI) and `@norcaster/verify` (npm). The
+top entry must match the release tag, `pyproject.toml` and `package.json`; the release workflow
+checks it.
+
+## 0.4.0 — first public release
+
+The first version published to PyPI and npm. It carries everything prepared as 0.3.0 (below,
+never released) and fixes from an internal pre-review of the Shared Record protocol and its
+verifiers (findings F-01 to F-11; an AI-assisted review by Norcaster, not the independent outside
+review). The protocol stays `shared-record/0`: no object format, digest or signature input
+changed. Verification rules did, and evidence that passed the unreleased 0.3.0 rules can fail or
+skip here; spec §16 lists each rule change.
+
+- **Revocation by log order (F-01).** For an object with a witnessed log position, a key revoked
+  by a key-document version registered before it is invalid whatever the object's `created_at`
+  says. `revoked_at` decides only for objects without a log position.
+- **One key per key id (F-03).** A key document is invalid when an entry's `key_id` is not the key
+  id of its PEM, when a version lists a key id twice, when a key id maps to another PEM than in an
+  earlier version, or when a later version undoes a revocation.
+- **Only witnessed positions order anything; several registrations (F-04).** Leaf indexes count
+  only from registrations a witnessed checkpoint covers. Each registration of an object is
+  verified and the earliest witnessed one is its position; identity is the object digest.
+- **No silent timestamp fallback; dispute profile (F-02, verifier side).** A logged object whose
+  organisation has a key-document version without a witnessed position gets `sender_key` /
+  `sender_agent` SKIP ("key history not fully logged"). Timestamps order only objects with no log
+  position, and the detail says so. `--profile dispute` (Python and Node) requires every logged
+  check to PASS (SKIP counts as FAIL) and adds `key_documents[org].complete` (SKIP: v0 evidence
+  cannot show the key history is complete). Reports carry `profile` and `evidence_complete_for`.
+- **Identical reports, no crashes (F-05, F-11).** Both verifiers read evidence and trust as text
+  under a strict JSON profile (spec §4.1): no number token with a fraction or exponent, no
+  `NaN`/`Infinity`, integers within ±(2^53 − 1), no duplicate member names, no unpaired
+  surrogates, at most 64 levels deep. New entry points `verify_evidence_text` (Python) and
+  `verifyEvidenceText` (Node); the CLIs use them and exit 2 on unusable input. Every object and
+  nested member is closed and typed; hex is lowercase only; timestamps are ASCII digits and real
+  dates in both; CBOR rejects map keys other than integers and text and nesting deeper than 16;
+  a protected header text starting with U+FEFF and a non-ASCII `kid` are refused. Nothing an
+  input contains makes either verifier raise.
+- **Acknowledgements (F-06).** Lateness is decided by the acknowledgement's log registration time
+  when it has one; a missing-acknowledgement record registered more than 300 s before the
+  deadline (log time) fails. Different acknowledgements (or missing-acknowledgement records) for
+  one receipt fail as conflicting. `content_check` is validated and `not_delivered` must match
+  `delivered: false`. New states `acknowledged_mismatch` and `acknowledged_blocked`; each exchange
+  has a `state_detail`.
+- **Sequence (F-07).** Two receipts with the same pair and sequence fail as a fork; a new `pairs`
+  section reports, per organisation pair, the numbers missing from the evidence.
+- **Validation (F-09, F-10).** `expires_at` is enforced (a key document is not in effect for
+  objects created or registered after it); revealed salts are exactly 32 bytes; acknowledgements'
+  `receiver.key_id` and missing-acknowledgement records' `recorded_by.key_id` must be the signing
+  key; unknown entry types fail. Quorum counts distinct witness keys; a trust configuration's
+  quorum must be from 1 to the number of witnesses.
+- **Report.** New sections `input` (where `format` now appears, with `trust`, `entries`,
+  `entry[i]`, `revealed`) and `pairs`; the check `receipt_fields` is gone (a malformed object is an
+  `entry[i]` FAIL and takes no further part). The report format stays
+  `norcaster.shared-record.report/0`.
+- **Vectors.** 25 vectors in `spec/vectors/` (16 new), each with its profile and its full report,
+  and 52 negative vectors in `spec/vectors/negative/` (malformed input, as text). Python and Node
+  must give byte-identical reports (canonical JSON) on all of them; a seeded differential fuzz
+  test compares the two on mutated vectors.
+
+## 0.3.0 — prepared, never released
+
+- **Shared Record verifier (draft protocol, in development).** Offline verification of Shared
+  Record evidence and dispute exports: key-document chains from a pinned root (including root
+  rotation signed by the old root), signing-key validity and revocation by log order, receipt,
+  acknowledgement and missing-acknowledgement signatures, content commitments for revealed
+  exchanges, RFC 9162 log inclusion and consistency, checkpoint signatures and witness quorum.
+  Python: `python -m norcaster_verify.shared_record verify EVIDENCE --trust TRUST`. Node:
+  `norcaster-verify-record EVIDENCE --trust TRUST`. Both give the same report on every vector.
+- **Protocol draft and review material:** `spec/shared-record-v0.md`, the nine test vectors in
+  `spec/vectors/` with their expected results, and `spec/REVIEW.md`, the brief for an outside
+  review.
+- **Audit bundles:** org-scoped decisions (no deployment) resolve their `org_policy_version`
+  against `org_policy_version_snapshots`.
+- **Examples:** `examples/audit-bundle.json`, a synthetic audit bundle for the README.
+- No tag was pushed and nothing was uploaded; 0.4.0 supersedes it.
+
+## 0.2.0 — prepared, never released
+
+- Audit-bundle verifier (`norcaster-verify`) and trace integrity proof verifier
+  (`norcaster-verify-proof`), prepared for the public repository and PyPI. No tag was pushed and
+  nothing was uploaded; 0.3.0 supersedes it.

norcaster_verify-0.4.0/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

norcaster_verify-0.4.0/PKG-INFO

@@ -0,0 +1,205 @@
+Metadata-Version: 2.5
+Name: norcaster-verify
+Version: 0.4.0
+Summary: Standalone verifier for Norcaster audit bundles: manifest content digest, integrity references, and public Rekor transparency-log anchors. Verifies evidence without a Norcaster account.
+Project-URL: Homepage, https://www.norcaster.com
+Project-URL: Documentation, https://www.norcaster.com/trust/integrity/algorithm
+Project-URL: Repository, https://github.com/norcaster/verify
+Project-URL: Issues, https://github.com/norcaster/verify/issues
+Author-email: "Norcaster (Navego AB)" <security@norcaster.com>
+License: Apache-2.0
+License-File: LICENSE
+Keywords: ai-governance,audit,eu-ai-act,evidence,rekor,soc2,verification
+Requires-Python: >=3.10
+Requires-Dist: httpx>=0.24
+Provides-Extra: signatures
+Requires-Dist: cryptography>=42; extra == 'signatures'
+Description-Content-Type: text/markdown
+
+# norcaster-verify
+
+Independent verification tooling for [Norcaster](https://www.norcaster.com) evidence. It verifies
+without a Norcaster account, without API access and without trusting Norcaster. Everything below
+runs offline.
+
+Two uses:
+
+1. **Verify an audit bundle**: the evidence package Norcaster exports for SOC 2 examinations and
+   EU AI Act readiness reviews (Python, `norcaster-verify` on PyPI).
+2. **Verify a Shared Record exchange or dispute export**: what two companies' agents exchanged,
+   signed by both and logged as hashes (Python or Node; the protocol is a draft, see below).
+
+The examples run from a clone of this repository, against files committed in it:
+
+```bash
+git clone https://github.com/norcaster/verify.git && cd verify
+```
+
+## 1. Verify an audit bundle
+
+```bash
+pip install norcaster-verify
+norcaster-verify examples/audit-bundle.json --offline
+```
+
+`examples/audit-bundle.json` is a small synthetic bundle. Expected result: `PASS`, with the
+content digest, governing configuration and approval provenance checks passing, and the trace
+chain snapshot and public Rekor anchors reported as `SKIP` because the example carries none. A
+SKIP is never a PASS.
+
+Change one recorded decision and verify again:
+
+```bash
+python -c "import json; b = json.load(open('examples/audit-bundle.json')); b['sections']['enforcement_records'][2]['outcome'] = 'allowed'; json.dump(b, open('tampered-bundle.json', 'w'))"
+norcaster-verify tampered-bundle.json --offline
+```
+
+Expected result: `FAIL` on the bundle content digest, exit code 1.
+
+For a real bundle, run `norcaster-verify bundle.json` (online, it looks up the Rekor anchors),
+`--offline` (it uses the Rekor snapshots embedded in the bundle) or `--json` (a machine-readable
+report). Exit code 0 means no check failed.
+
+What it checks:
+
+- the manifest's content digest;
+- the internal integrity references;
+- the public Sigstore Rekor anchors;
+- **governing-configuration consistency**: every enforcement decision's
+  `deployment_policy_version` / `policy_content_hash` resolves to a policy snapshot in the bundle
+  whose hash recomputes. Org-scoped decisions, which have no deployment, resolve their
+  `org_policy_version` against `org_policy_version_snapshots`;
+- **approval provenance**: policy versions produced by a config proposal name an independent
+  approver and appear in `change_history`.
+
+For anchors written by a signing-enabled chain it also checks that the Rekor entry embeds the
+tenant's public key named in the manifest and a valid ES256 signature over the segment root. That
+needs `pip install "norcaster-verify[signatures]"`; without `cryptography` that part reports
+SKIP, not PASS.
+
+The same two files (`verify_audit_bundle.py`, `audit_bundle_verify_lib.py`) ship inside every
+Norcaster audit-bundle zip. This package and the bundled copies are interchangeable, and a test
+enforces that they are identical byte for byte.
+
+## 2. Verify a Shared Record exchange or dispute export
+
+A Shared Record export is one JSON evidence file: the signed receipts, acknowledgements and
+missing-acknowledgement records for the exchanges in question, their log proofs, a witnessed
+checkpoint, both organisations' key documents and, for exchanges a party chose to reveal, the
+content and salt. You verify it against **your own** trust file: the root fingerprints you pinned
+for each organisation and the log and witness keys you trust.
+
+Each test vector in `spec/vectors/` holds both, plus the expected result. Split one into the two
+files the verifier takes:
+
+```bash
+python -c "import json; v = json.load(open('spec/vectors/valid-acknowledgement.json')); json.dump(v['evidence'], open('evidence.json', 'w')); json.dump(v['trust'], open('trust.json', 'w'))"
+```
+
+Python:
+
+```bash
+pip install "norcaster-verify[signatures]"
+python -m norcaster_verify.shared_record verify evidence.json --trust trust.json
+```
+
+Node (18 or later), the same checks:
+
+```bash
+npx --yes --package @norcaster/verify norcaster-verify-record evidence.json --trust trust.json
+```
+
+Expected result: the exchange `state=acknowledged`, `Result: no check failed` and exit code 0.
+Every check passes except two that do not apply here and say so as `SKIP`: there is no
+missing-acknowledgement record, and the evidence holds one checkpoint, so there is no earlier one
+to prove consistency with. The receipt's content commitment is checked against the revealed
+content and salt (`content_commitment: revealed content and salt match the commitment`).
+
+Now a copy whose receipt was changed after it was signed:
+
+```bash
+python -c "import json; v = json.load(open('spec/vectors/tampered-content-hash.json')); json.dump(v['evidence'], open('evidence.json', 'w')); json.dump(v['trust'], open('trust.json', 'w'))"
+python -m norcaster_verify.shared_record verify evidence.json --trust trust.json
+```
+
+Expected result: `FAIL` on the receipt signature, the content commitment and the receipt's log
+inclusion, and exit code 1. Add `--json` to either command for a machine-readable report. Without
+the `signatures` extra the Python verifier reports signature checks as SKIP, never PASS; Node
+always checks them. Python and Node give the same report, byte for byte, on every input.
+
+**Profiles.** The default, `--profile basic`, reports what the evidence shows. For a dispute, add
+`--profile dispute`: every log check (receipts, acknowledgements, missing-acknowledgement records,
+key-document versions and root rotations) must then PASS, and a SKIP counts as a FAIL. Either way
+the report says, per organisation (`evidence_complete_for`), that the result assumes the export
+holds the organisation's complete key history, which v0 evidence cannot show:
+
+```bash
+python -m norcaster_verify.shared_record verify evidence.json --trust trust.json --profile dispute
+```
+
+**Input.** Both verifiers read the evidence and trust files as text under a strict JSON profile
+(spec §4.1): no number with a fraction or an exponent, no `NaN`, no duplicate member names. A file
+outside it is unusable input: the report's `input` section says why, and the exit code is 2. From
+code, use `verify_evidence_text(evidence_text, trust_text, profile="basic")` in Python or
+`verifyEvidenceText(evidenceText, trustText, { profile })` in Node; `verify_evidence` and
+`verifyEvidence` take parsed JSON, which can no longer show those mistakes.
+
+The 25 vectors and what each must give are listed in `spec/vectors/`, and 52 negative vectors
+(malformed input, as text) in `spec/vectors/negative/`. An export from a Norcaster organisation
+(`POST /orgs/{org}/shared-record/dispute-exports`) or from the self-hosted counterparty component
+(`norcaster-counterparty export`) verifies the same way.
+
+### Shared Record status
+
+In development · pilot pairs by application. A pilot version is built and in testing. It is not
+in production or available to customers.
+
+`spec/shared-record-v0.md` is a **draft protocol, in development, published for review**. It is
+designed on the IETF SCITT architecture (RFC 9943), using COSE hash envelopes (RFC 9995), COSE
+Receipts (RFC 9942) and the RFC 9162 Merkle tree. It may change. The Python module
+`norcaster_verify.shared_record` is its reference implementation and `lib/shared-record/` its
+Node verifier. `spec/REVIEW.md` is the brief for an outside review of the protocol. The record
+shows what each party signed and what the log recorded; it does not decide who is right.
+
+## 3. Verify a trace integrity proof (Node)
+
+Verifies a per-run **trace integrity proof bundle** (`norcaster-proof-<run_id>.json`): the local
+hash-chain proof, the Merkle path, and one Rekor lookup to confirm the segment root against the
+public transparency log. This one is online.
+
+```bash
+npx --yes --package @norcaster/verify norcaster-verify-proof --proof norcaster-proof-<run_id>.json
+```
+
+What it checks: the recorded chain-proof result carried in the bundle, the Merkle inclusion path
+when one is present, the tenant-key (ES256) signature over the entry and, where the Merkle path
+allows, over the segment root, and that the segment root and public key in the Rekor entry match
+what the bundle carries. It does not recompute the full hash chain, and the Rekor URL comes from
+the bundle itself. See `docs/algorithm.md` for exactly what each step proves. Unsigned
+(version 1) bundles are reported as `unsigned`, never as verified. The npm package installs two
+commands, `norcaster-verify-proof` and `norcaster-verify-record`, distinct from the Python
+`norcaster-verify` command.
+
+## What verification does not prove
+
+Completeness of an AI estate, compliance with any framework, or authenticity of the export
+source. Norcaster produces evidence; only a licensed CPA firm can attest under SOC 2, and EU AI
+Act conformity determinations require qualified counsel. A Shared Record verification shows what
+was signed and logged, not which party is right about a dispute.
+
+## Source and releases
+
+This repository is a published snapshot of `packages/norcaster-verify` in Norcaster's main
+repository, which is the source of truth. The Python files here are byte-for-byte the ones that
+ship inside every audit-bundle zip, and a test in the main repository enforces that. Open issues
+here.
+
+Releases are cut from version tags (`v0.4.0`). The `release.yml` workflow builds the Python sdist
+and wheel and publishes them to PyPI, and publishes the npm package, using each registry's
+trusted-publishing (OIDC) flow, with no long-lived tokens. The versions in `pyproject.toml` and
+`package.json` and the top entry of `CHANGELOG.md` must all equal the tag. CI runs the Node and
+Python tests on every push.
+
+Security reports: see [SECURITY.md](SECURITY.md).
+
+Apache-2.0 · security@norcaster.com