scientific-computing-system 2.2.1__tar.gz → 2.2.2__tar.gz

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/.github/workflows/cli-package-smoke.yml

@@ -33,10 +33,15 @@ jobs:
         with:
           python-version: "3.12"
       - name: Build wheel
+        # bash, not the Windows default PowerShell: `set -euo pipefail` is bash
+        # syntax and pwsh rejects it with "A parameter cannot be found that
+        # matches parameter name 'euo'". The other steps in this job pin the
+        # shell for the same reason.
+        shell: bash
         run: |
-          python -m pip install --upgrade pip
-          pip install build
-          python -m build --wheel
+          set -euo pipefail
+          python -m pip install --require-hashes --only-binary=:all: -r requirements-build.lock
+          python -m build --wheel --no-isolation
       - name: Install wheel instead of source tree
         shell: bash
         run: |

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/.github/workflows/release.yml

@@ -179,6 +179,20 @@ jobs:
       - name: Build sdist + wheel without dependency isolation
         run: python -m build --no-isolation
 
+      # Validate the core metadata *rendered* from the artifacts, before anything
+      # is uploaded. `check_version_lockstep.py` proves the version and name are
+      # right; it does not prove the artifact is renderable at all. This is the
+      # step that catches an unusable artifact while it is still local.
+      #
+      # The pin matters and is not cosmetic. twine <= 6.2.0 replaces
+      # `packaging.metadata._VALID_METADATA_VERSIONS` at import time with a list
+      # ending at 2.4, so it rejects a valid artifact with
+      # `InvalidDistribution: '2.5' is not a valid metadata version` -- a release
+      # failure with nothing wrong with the package. twine 7.0.0 (pinned in
+      # requirements-build.lock) removed the override.
+      - name: Validate artifact metadata renders
+        run: python -m twine check --strict dist/*
+
       # Assert the *contents* of both artifacts before anything is published.
       # The version/name verification below proves the metadata says 2.1.0; this
       # proves the wheel actually ships `cds` with its `py.typed` marker and the

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/.github/workflows/tests.yml

@@ -307,6 +307,53 @@ jobs:
         run: python scripts/check_version_discipline.py --base-ref "${{ steps.base.outputs.ref }}"
       - name: Reject version metadata lockstep drift
         run: python scripts/check_version_lockstep.py
+      # The release toolchain must stay pinned, and the twine pin must stay able
+      # to validate the Metadata-Version the build backend actually emits --
+      # twine<=6.2.0 overrides packaging's list at import time and rejects valid
+      # artifacts with `'2.5' is not a valid metadata version`.
+      #
+      # GITHUB_TOKEN is passed so the advisory upstream checks authenticate.
+      # Unauthenticated GitHub API calls are capped at 60/hour, which is easy to
+      # exceed and fails in a way that looks like success: a sibling guard
+      # "verified" pins under rate limiting and silently verified nothing.
+      # Fast, offline, workflow-shape gate: pins and `twine check --strict` usage.
+      # The authoritative run, including the twine/Metadata-Version compatibility
+      # check, is in the `packaging` job below -- the only job that has built
+      # artifacts to read the emitted Metadata-Version from.
+      - name: Reject unpinned release toolchain
+        run: python scripts/check_release_toolchain.py --skip-network
+      # The provenance prose asserts, per registry, whether the published
+      # release carries a build attestation. That claim was originally written
+      # from memory and nothing checked it, so it could have kept being
+      # asserted after a release changed the answer. This runs the committed
+      # guard (`docs/checks/verify_provenance_claims.py`) against the live
+      # registries and fails if the prose contradicts them.
+      #
+      # Placed here rather than in a new job on purpose: this job already owns
+      # release-metadata verification and already sits in the required `CI`
+      # aggregate, so this strengthens an existing gate instead of adding a
+      # required check that would need a ruleset change. `permissions:
+      # contents: read` above is sufficient -- the guard only reads PyPI and npm,
+      # never the GitHub API, so no token is needed.
+      #
+      # `--strict-network` is deliberately NOT set: a registry outage is
+      # reported as UNKNOWN and the run passes with a NOTICE, because a required
+      # gate that fails on a DNS blip teaches people to re-run it rather than
+      # read it. A false claim still fails. The unit test
+      # (`tests/test_provenance_claims.py`) is the deterministic gate and needs
+      # no network at all.
+      #
+      # The version is read from `pyproject.toml` rather than hardcoded: a
+      # literal here would go stale at the next release, which is the same class
+      # of stale-constant bug this step exists to catch. A version that has not
+      # shipped yet is reported as unverifiable rather than "unattested", so a
+      # bump PR is not blocked by asking about a release that does not exist.
+      - name: Reject provenance claims that contradict the live registries
+        run: >-
+          python docs/checks/verify_provenance_claims.py
+          --version "$(python -c 'import tomllib, pathlib;
+          print(tomllib.loads(pathlib.Path("pyproject.toml").read_text(encoding="utf-8"))
+          ["project"]["version"])')"
 
   packaging:
     name: built wheel and sdist contents on Linux with Python 3.12
@@ -332,6 +379,19 @@ jobs:
         run: python scripts/check_version_lockstep.py --dist-dir dist
       - name: Assert wheel and sdist contents
         run: python scripts/check_distribution_contents.py dist
+      # Read the Metadata-Version out of the artifacts just built and prove the
+      # pinned twine can validate it. twine<=6.2.0 overrides packaging's
+      # metadata-version list at import time and rejects a valid artifact with
+      # `'2.5' is not a valid metadata version`; a sibling release failed that
+      # way with nothing wrong with the package.
+      #
+      # GITHUB_TOKEN is passed so the advisory upstream checks authenticate.
+      # Unauthenticated GitHub API calls are capped at 60/hour, and under rate
+      # limiting a pin check can silently verify nothing while reporting success.
+      - name: Assert the pinned twine can validate the built metadata
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+        run: python scripts/check_release_toolchain.py --dist-dir dist
       # A source distribution whose own test suite cannot pass is not a source
       # distribution. 13 release-contract tests used to fail here because
       # `.github/workflows` was missing from the sdist; this step is what keeps

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/CHANGELOG.md

@@ -7,6 +7,138 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [v2.2.2] - 2026-10-05
+
+Clears the last 17 open CodeQL alerts in this repository. None of them was a
+security vulnerability, and **none was a logic defect** — no discarded result, no
+missing `return`. Nothing is suppressed: there is no `# nosec`, no path exclusion
+and no `codeql.config` entry.
+
+### Behaviour change
+
+**One, and it is a removal:** the private path `cds.cli._parser._build_parser` no
+longer resolves.
+
+`_build_parser` was an alias for `build_parser`, kept for backwards
+compatibility. It was defined in `cds.cli._parser` but imported and re-exported by
+`cds.cli.__init__`, so within its own module it was genuinely unreferenced —
+which is exactly what `py/unused-global-variable` reported. The assignment has
+moved to `cds.cli.__init__`, beside its only consumer and inside the `__all__`
+that already exports it.
+
+- `cds.cli._build_parser` is unchanged: still present, still in `__all__`, still
+  the same object as `cds.cli.build_parser`. This is the documented
+  backwards-compatibility surface and it keeps working.
+- `cds.cli._parser._build_parser` is gone. Nothing in this repository referenced
+  it and the name is underscore-private, but a downstream script that reached
+  into the private submodule would break.
+
+There is now a test pinning the alias, because the original defect was that
+nothing asserted it existed.
+
+### Fixed
+
+- **Protocol placeholders are docstrings, not bare `...`.** Nine
+  `py/ineffectual-statement` alerts across `src/cds/ml/model_selection.py`,
+  `src/cds/ml/voting.py` and `src/cds/tools/adapters.py` were the conventional
+  `...` terminating a `typing.Protocol` method. These are false positives in the
+  strict sense: `...` is the documented placeholder for a structurally-typed
+  method whose implementation lives in the real backend module, and no code path
+  executes it. `SoftVotingModel` is the only `@runtime_checkable` one, and
+  `isinstance` against a runtime protocol inspects attribute *presence* without
+  calling the body.
+
+  They became docstrings rather than `pass` because coverage.py excludes an
+  ellipsis-only body but counts `pass`; measured, swapping it in drops those
+  lines from 100% to 75% and breaks the coverage gate. `raise NotImplementedError`
+  has the same coverage problem and would additionally change behaviour if the
+  body were ever reached. `src/cds` already contained nine docstring-only bodies
+  with no alert on any of them.
+
+- **`src/cds/tools/registry.py` imports `importlib` one way.** Three spellings
+  were mixed: `import importlib`, `import importlib.util` and
+  `from importlib import metadata`. The first was fully subsumed by the second.
+  Now `import importlib.metadata` and `import importlib.util`, with call sites
+  fully qualified. Four monkeypatch targets in `tests/` were retargeted to match.
+
+- **Four `py/unnecessary-lambda` alerts in the test suite.** `lambda x: max(x)`
+  and `lambda values: sum(values)` are plain wrappers around a callable; the
+  callables are now passed directly.
+
+- **`tests/test_fitting_bootstrap.py` imports `cds.modeling.fitting` one way.**
+  A module-level `from ... import` coexisted with function-local
+  `import ... as fitting`. The single `import ... as fitting` form is used now and
+  the module-level names are qualified through it.
+
+### Added
+
+- **`tests/test_protocol_placeholders.py`** pins the protocol bodies on the AST,
+  because a docstring-only body and a docstring followed by `pass` compile to
+  almost identical instructions and only the syntax tree tells them apart. It also
+  asserts the placeholder semantics (`None` when called unbound), that
+  `SoftVotingModel` is still a working structural contract, and that every
+  declared signature and annotation still resolves. Negative-controlled against
+  four mutations, all caught: docstring-plus-`pass`, `...` reinstated, body
+  replaced by a real statement, and a statement appended after the docstring.
+
+### Changed
+
+- README's pasted `cds --version` transcript now reads `System version 2.2.2`.
+  Every provenance and attestation statement in `README.md` and `SECURITY.md`
+  still refers to **2.2.1** deliberately: those describe the published release,
+  including its digests, and remain true until a newer one ships.
+
+
+### Fixed
+
+- **Provenance claims are now scoped, measured, and guarded.** A follow-up report
+  asserted that PyPI had no PEP 740 attestation either. Re-measured directly, that
+  is **not** the case, so the previous text was left standing and made precise
+  rather than weakened:
+
+  - PyPI **2.2.1** serves a PEP 740 provenance bundle for **both** the wheel and
+    the sdist (HTTP 200 on the per-file `/integrity/.../provenance` endpoint),
+    and each bundle's `subject` digest equals the `sha256` PyPI publishes for
+    that file. The 404 in the report came from requesting
+    `https://pypi.org/integrity/scientific-computing-system/2.2.1/`, which is a
+    directory, not the per-file endpoint.
+  - npm **2.2.1** has **no** attestation: the attestations endpoint returns 404.
+    This part of the report was correct.
+
+  The security posture is therefore unchanged and more precisely stated. What
+  changed: `SECURITY.md` now separates the three things that were being conflated
+  — a **PEP 740 attestation** (Sigstore-signed, attests *who built this*),
+  **npm `dist.signatures`** (registry transport signing, attests nothing about
+  the build), and a **content digest** (`sha256` on PyPI, `dist.integrity` on
+  npm; pins *which bytes*, not *where they came from*). It lists the published
+  digests to pin, gives the commands that verify them, and states the exact
+  trusted-publisher coordinates still to be registered for npm.
+
+- **Reproducible-build claim scoped to what was actually measured.** Two
+  consecutive builds of the same commit with the same pinned backend produced
+  byte-identical wheel and sdist. Those digests do **not** match the published
+  ones (the release runs a hash-locked Linux toolchain; the check ran elsewhere),
+  so the documentation now claims determinism for a fixed toolchain and
+  explicitly declines to claim the published artifacts are bit-for-bit
+  reproducible from source.
+
+- **npm launcher prerequisite re-verified.** With `cds` absent from `PATH`, the
+  shim proceeds straight to interpreter resolution (`python`/`python3`/`py`) and
+  runs `python -m cds`; it never looks for a `cds` console script. README,
+  `SECURITY.md` and the docs already agreed on this wording, and it is now
+  backed by an explicit check rather than by reading the source.
+
+### Added
+
+- `docs/checks/verify_provenance_claims.py` — a guard that parses the attestation
+  claims out of `README.md` and `SECURITY.md` and compares them against the live
+  registries, failing if the prose asserts something the registries contradict.
+  It also rejects prose that overstates `dist.integrity` as provenance or allows
+  the attested subject to differ from the published digest. Negative-controlled:
+  three false claims (PyPI not attested, npm attested, digest mismatch acceptable)
+  each turn it red. Wiring it into CI is left to the workflow owner; this change
+  is docs-only by scope.
+
 ## [v2.2.1] - 2026-10-04
 
 Documentation and release-surface corrections. **No library behaviour change**:

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/CITATION.cff

@@ -5,7 +5,7 @@ title: "scientific-computing-system"
 # Keep `version` in lockstep with pyproject.toml [project].version and
 # src/cds/_version.py. scripts/check_version_discipline.py and
 # scripts/check_version_lockstep.py enforce this.
-version: 2.2.1
+version: 2.2.2
 authors:
   - name: "Furox-Art"
     email: "furkanarkn1451@gmail.com"
@@ -21,7 +21,7 @@ abstract: >-
 license: MIT
 repository-code: "https://github.com/Furox-Art/scientific-computing-system"
 url: "https://github.com/Furox-Art/scientific-computing-system"
-date-released: "2026-10-04"
+date-released: "2026-10-05"
 keywords:
   - "pure python"
   - "scientific computing"
@@ -50,5 +50,5 @@ preferred-citation:
   authors:
     - name: "Furox-Art"
   year: 2026
-  version: 2.2.1
+  version: 2.2.2
   url: "https://github.com/Furox-Art/scientific-computing-system"

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: scientific-computing-system
-Version: 2.2.1
+Version: 2.2.2
 Summary: A pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, scientific workflows, dimensional analysis, and optional research-data backends. Zero runtime dependencies.
 Project-URL: Homepage, https://github.com/Furox-Art/scientific-computing-system
 Project-URL: Repository, https://github.com/Furox-Art/scientific-computing-system
@@ -146,10 +146,20 @@ The import name is **`cds`** (the distribution is `scientific-computing-system`)
 | **npm** (a launcher shim) | `npm i -g scientific-computing-system` | A thin Node wrapper that runs `python -m cds`. It ships no Python and needs the Python distribution installed so that `python -m cds` resolves. |
 
 Both channels are published at the same version. They are **not** equally
-verifiable: the PyPI release carries a PEP 740 provenance attestation, while the
-currently published npm release does not. Prefer PyPI for anything
-security-sensitive — [SECURITY.md](SECURITY.md#distribution-channels-and-provenance)
-has the per-channel comparison.
+verifiable:
+
+- **PyPI** — carries a **PEP 740 provenance attestation** (Sigstore-signed,
+  binding the file digest to the publishing workflow). Verified on 2.2.1.
+- **npm** — carries **no** attestation; the npmjs.com trusted publisher is not
+  registered yet, so its publish path cannot mint one. npm does expose
+  `dist.integrity` (sha512), which is a content pin, not proof of origin, and
+  `dist.signatures`, which is npm's registry transport signature, not build
+  provenance.
+
+Prefer PyPI for anything security-sensitive.
+[SECURITY.md](SECURITY.md#distribution-channels-and-provenance) has the
+per-channel table, the published digests to pin, the commands to verify them,
+and what to register to close the npm gap.
 
 ## What's inside
 
@@ -259,7 +269,7 @@ The package installs a `cds` command with 13 subcommands:
 
 ```console
 $ cds --version
-System version 2.2.1
+System version 2.2.2
 $ cds constants        # physical constants table
 ```
 

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/README.md

@@ -50,10 +50,20 @@ The import name is **`cds`** (the distribution is `scientific-computing-system`)
 | **npm** (a launcher shim) | `npm i -g scientific-computing-system` | A thin Node wrapper that runs `python -m cds`. It ships no Python and needs the Python distribution installed so that `python -m cds` resolves. |
 
 Both channels are published at the same version. They are **not** equally
-verifiable: the PyPI release carries a PEP 740 provenance attestation, while the
-currently published npm release does not. Prefer PyPI for anything
-security-sensitive — [SECURITY.md](SECURITY.md#distribution-channels-and-provenance)
-has the per-channel comparison.
+verifiable:
+
+- **PyPI** — carries a **PEP 740 provenance attestation** (Sigstore-signed,
+  binding the file digest to the publishing workflow). Verified on 2.2.1.
+- **npm** — carries **no** attestation; the npmjs.com trusted publisher is not
+  registered yet, so its publish path cannot mint one. npm does expose
+  `dist.integrity` (sha512), which is a content pin, not proof of origin, and
+  `dist.signatures`, which is npm's registry transport signature, not build
+  provenance.
+
+Prefer PyPI for anything security-sensitive.
+[SECURITY.md](SECURITY.md#distribution-channels-and-provenance) has the
+per-channel table, the published digests to pin, the commands to verify them,
+and what to register to close the npm gap.
 
 ## What's inside
 
@@ -163,7 +173,7 @@ The package installs a `cds` command with 13 subcommands:
 
 ```console
 $ cds --version
-System version 2.2.1
+System version 2.2.2
 $ cds constants        # physical constants table
 ```
 

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/SECURITY.md

@@ -29,8 +29,8 @@ It is also published to npm as `scientific-computing-system`, but that package i
 
 | Threat | Mitigation |
 |---|---|
-| **Supply chain: malicious or substituted PyPI artifact** | The release workflow is the sole PyPI publish authority. It builds wheel + sdist on a GitHub-hosted runner, verifies package metadata/version, installs the built wheel, smoke-tests the installed CLI, generates GitHub artifact attestation for those exact runner-local files, and publishes through PyPI Trusted Publishing (OIDC). PyPI serves a PEP 740 provenance bundle for both artifacts. |
-| **Supply chain: malicious or substituted npm artifact** | The npm workflow is the sole npm publish authority and gates on the registry version-existence check, a `npm pack --dry-run` tarball allowlist, and npm/Python version lockstep. **Provenance depends on the publish mode:** the OIDC path publishes with `--provenance` and yields a Sigstore attestation; the token fallback path cannot mint one and deliberately publishes without it. See below for the status of the currently published npm release. |
+| **Supply chain: malicious or substituted PyPI artifact** | The release workflow is the sole PyPI publish authority. It builds wheel + sdist on a GitHub-hosted runner from a hash-pinned toolchain, verifies package metadata/version, installs the built wheel, smoke-tests the installed CLI, and publishes through PyPI Trusted Publishing (OIDC). PyPI serves a PEP 740 provenance bundle for 2.2.1 whose subject digest matches the published `sha256`. |
+| **Supply chain: malicious or substituted npm artifact** | The npm workflow is the sole npm publish authority and gates on the registry version-existence check, a `npm pack --dry-run` tarball allowlist, and npm/Python version lockstep. **No attestation is possible yet:** the npmjs.com trusted publisher is not registered, so the token fallback is the working mode and npm's `--provenance` cannot be honoured. Consumers can only pin `dist.integrity` until that is registered. See below. |
 | **Registry drift** | Public PyPI is treated as the distribution registry for the library. The release integrity check requires exactly one wheel and one sdist on PyPI and requires the matching GitHub Release to contain no wheel/sdist assets. A registry-policy workflow rechecks the public PyPI package and removes accidental distribution assets from GitHub Releases. |
 | **Dependency vulnerabilities** | The core has no required runtime dependencies. Development/test/docs lock files are audited in CI with `pip-audit`; optional backends are isolated behind extras and lazy loading. |
 | **Code execution from package install** | The build backend is `hatchling`; there is no `setup.py` execution and package versioning is static in `pyproject.toml` plus `src/cds/_version.py`. |
@@ -40,26 +40,100 @@ It is also published to npm as `scientific-computing-system`, but that package i
 
 ### Distribution channels and provenance
 
+The two channels carry **different** artifacts and **different** verification
+properties. This section states exactly what is verifiable today. It is
+version-specific; re-check it rather than trusting it indefinitely.
+
 | | PyPI `scientific-computing-system` | npm `scientific-computing-system` |
 |---|---|---|
 | Contents | the library (wheel + sdist) | `index.js`, `bin/scs.js`, `LICENSE`, `README.md`, `CHANGELOG.md`, `SECURITY.md` — **no Python** |
-| Requires the other channel | no | yes; `scs` needs the Python distribution installed so that `python -m cds` resolves — it does **not** look for a `cds` console script on `PATH` |
-| Publish authentication | Trusted Publishing (OIDC) | OIDC trusted publishing is implemented and is the default; a token fallback exists |
-| Attestation on the currently published release | **not on 2.2.0** — that release predates Trusted Publishing on this path and PyPI serves zero PEP 740 bundles for it; **yes from 2.2.1**, published via Trusted Publishing | **no** — the published 2.2.0 went out in token mode, which cannot produce a Sigstore attestation |
-
-The npm release published as 2.2.0 was produced by a manual dispatch with
-`use_token_fallback=true`. A long-lived registry token has no build identity to
-attest, so npm's `--provenance` flag cannot be honoured on that path; the
-workflow omits the flag and prints a notice instead of publishing something that
-looks attested and is not. `npm view <pkg>` reports a legacy `dist.signatures`
-value for it, which is npm's own transport signing and **not** a build
-provenance attestation; the npm attestations endpoint returns 404 for this
-package at this version.
-
-**Practical consequence:** for anything security-sensitive, install from PyPI
-and verify the PEP 740 provenance bundle against the SHA-256 digests PyPI
-publishes. Do not rely on the npm channel for supply-chain assurance until a
-release is published through the OIDC path.
+| Requires the other channel | no | yes; `scs` runs `python -m cds`, so the Python distribution must be installed. It resolves `python`/`python3`/`py` and does **not** look for a `cds` console script on `PATH` |
+| Publish authentication | Trusted Publishing (OIDC) | OIDC trusted publishing implemented and default; token fallback exists |
+| **PEP 740 provenance attestation** | **yes on 2.2.1** (verified; see below) | **none** — attestations endpoint returns 404 |
+| **npm `dist.signatures`** | n/a | present — registry transport signature, **not** build provenance |
+| **Content digest a consumer can pin** | `sha256` per file on the PyPI file page | `dist.integrity` (sha512) and `dist.shasum` (sha1) |
+
+#### Three things that are easy to confuse
+
+1. **A PEP 740 provenance attestation** is a Sigstore-signed statement binding a
+   file digest to the identity and workflow that published it. PyPI serves it
+   from `/integrity/<project>/<version>/<filename>/provenance`. It is the only
+   one of the three that attests *who built this*.
+2. **npm's `dist.signatures`** is npm signing its own registry metadata for
+   transport integrity. It proves the metadata came from npm's key. It says
+   nothing about who built the tarball, and it is not a provenance attestation.
+3. **A content digest** (`sha256` on PyPI, `dist.integrity`/`dist.shasum` on npm)
+   pins *which bytes* you get. Useful for integrity and for detecting a
+   substituted file; on its own it proves nothing about origin, because anyone
+   who substitutes a file also substitutes its digest.
+
+#### What is published today, and how to check it
+
+Verified against the live registries for **PyPI 2.2.1**:
+
+```bash
+# PEP 740 attestation exists (HTTP 200). Note the per-FILE path; a bare
+# /integrity/<project>/<version>/ directory is not an endpoint and 404s.
+curl -sS -H "Accept: application/vnd.pypi.integrity.v1+json" \
+  https://pypi.org/integrity/scientific-computing-system/2.2.1/scientific_computing_system-2.2.1-py3-none-any.whl/provenance
+
+# The digest PyPI publishes for that file, to compare against the attestation
+# subject (predicateType https://docs.pypi.org/attestations/publish/v1):
+curl -sS https://pypi.org/pypi/scientific-computing-system/2.2.1/json | python -c \
+  "import json,sys; [print(f['filename'], f['digests']['sha256']) for f in json.load(sys.stdin)['urls']]"
+
+# npm: no attestation; there IS a transport signature and an integrity digest.
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://registry.npmjs.org/-/npm/v1/attestations/scientific-computing-system@2.2.1   # -> 404
+npm view scientific-computing-system@2.2.1 dist.integrity dist.shasum
+```
+
+The published PyPI 2.2.1 digests, useful for pinning:
+
+| File | sha256 |
+|---|---|
+| `scientific_computing_system-2.2.1-py3-none-any.whl` | `b14b89478fdc8b11482ffd556bb6eb59c6b21887f2a09418edec7029d4569bb9` |
+| `scientific_computing_system-2.2.1.tar.gz` | `6ba4ad4c2ebb6bef86356bcbcd251e12978737945e58d9e75b9c68860efa77f6` |
+
+Both were confirmed to equal the `subject` digest inside their attestation
+bundles, so the attested bytes and the published bytes are the same bytes.
+
+#### Reproducible builds: what is and is not claimed
+
+The build toolchain is hash-pinned (`requirements-build.lock`, installed with
+`--require-hashes --only-binary=:all:`) and the release workflow runs
+`python -m build --no-isolation` on that lock.
+
+Two consecutive builds of the same commit with the same pinned backend produced
+**byte-identical** wheel and sdist (sha256 `c7734fb5…` and `daa7dca2…`).
+
+Those digests **do not** match the published ones, because that check ran on a
+different platform with a locally installed backend rather than the release's
+hash-locked Linux toolchain. So the honest statement is: *the build is
+deterministic for a fixed toolchain, and this repository does not currently
+claim that the published artifacts are bit-for-bit reproducible from source.*
+Treat the published digests above as the pin to use, not a rebuild target.
+
+#### When provenance will appear
+
+The OIDC plumbing is implemented on both sides; the registries-side trusted
+publisher records are **not yet in place**, so an npm release cannot carry an
+attestation yet:
+
+- **PyPI** — Trusted Publisher: owner `Furox-Art`, repository
+  `scientific-computing-system`, workflow `release.yml`, environment `pypi`.
+  Already exercised: 2.2.1 was published through it and is attested.
+- **npm** — Trusted Publisher: owner `Furox-Art`, repository
+  `scientific-computing-system`, workflow `npm-publish.yml`, environment `npm`.
+  **Pending registration.** Until it exists, the default OIDC path cannot
+  complete a publish, and the token fallback — which cannot mint a Sigstore
+  identity — is the only working mode. That is why the published npm artifacts
+  have no attestation.
+
+**Practical consequence:** for anything security-sensitive, install from PyPI and
+check the PEP 740 bundle against the digests PyPI publishes. Do not rely on the
+npm channel for supply-chain assurance today; treat its `dist.integrity` as an
+integrity pin only.
 
 ### Optional Backend Boundary
 
@@ -87,7 +161,7 @@ In particular, `sympy_verify_identity()` passes caller-provided symbolic strings
 
 1. **Pin the package version** in reproducible environments, for example `pip install "scientific-computing-system==X.Y.Z"` with the exact release you have evaluated, rather than an unconstrained range. Deliberately no concrete version is written here: a pinned example goes stale at the next release and readers copy it regardless, so take the number from the [release notes](https://github.com/Furox-Art/scientific-computing-system/releases) for the release you are deploying, and record it in your own lockfile or constraints file.
 2. **Install only the optional extras you need.** Fewer third-party packages reduce supply-chain and compatibility surface.
-3. **Verify provenance for high-assurance use.** Compare the PyPI wheel/sdist SHA-256 digests with the subjects recorded by the GitHub release workflow's artifact attestation, or fetch the PEP 740 provenance bundle from PyPI. There is currently **no** equivalent attestation for the npm package — see [Distribution channels and provenance](#distribution-channels-and-provenance).
+3. **Verify provenance for high-assurance use.** For PyPI, fetch the PEP 740 bundle from `/integrity/<project>/<version>/<filename>/provenance` and confirm its `subject` digest equals the `sha256` PyPI publishes for that file. There is currently **no** attestation for the npm package; its `dist.integrity` is an integrity pin, not provenance. See [Distribution channels and provenance](#distribution-channels-and-provenance).
 4. **Treat optional backend inputs as backend inputs.** Do not pass hostile symbolic expressions or untrusted scientific files without the validation/sandboxing appropriate to SymPy, HDF5, NetCDF, or the relevant backend.
 5. **Keep the environment current.** Review dependency updates and run vulnerability auditing against the exact environment deployed.
 6. **Do not use the library as the sole validation layer for safety-critical conclusions.** Independent domain validation remains necessary.

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.2}/codemeta.json

@@ -2,7 +2,7 @@
   "@context": "https://doi.org/10.5063/schema/codemeta-2.0",
   "@type": "SoftwareSourceCode",
   "name": "scientific-computing-system",
-  "version": "2.2.1",
+  "version": "2.2.2",
   "description": "Pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, and scientific workflows. Zero runtime dependencies. This is the front door; scientific-computing-system-2.0 is the NumPy build of the same work.",
   "license": "https://spdx.org/licenses/MIT",
   "codeRepository": "https://github.com/Furox-Art/scientific-computing-system",
@@ -17,7 +17,7 @@
       "name": "Furox-Art"
     }
   ],
-  "datePublished": "2026-10-04",
+  "datePublished": "2026-10-05",
   "keywords": [
     "scientific computing",
     "numerical methods",