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

{scientific_computing_system-2.2.2 → scientific_computing_system-2.2.4}/.github/workflows/changelog.yml

@@ -53,7 +53,7 @@ jobs:
           fetch-depth: 0
 
       - name: Install git-cliff
-        uses: orhun/git-cliff-action@3d96a18cc4ec17e9dc69ddcc424ccafaf1f78ce2 # v4
+        uses: orhun/git-cliff-action@a9a95522b26fe6403f7bb24031f21fb573d0f5ff # v4
         with:
           config: cliff.toml
           args: --verbose --tag ${{ inputs.tag }} --output CHANGELOG.md

{scientific_computing_system-2.2.2 → scientific_computing_system-2.2.4}/.github/workflows/codeql.yml

@@ -43,13 +43,13 @@ jobs:
         with:
           persist-credentials: false
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4
+        uses: github/codeql-action/init@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4
         with:
           languages: ${{ matrix.language }}
           queries: security-and-quality
       - name: Autobuild
-        uses: github/codeql-action/autobuild@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4
+        uses: github/codeql-action/autobuild@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4
       - name: Perform CodeQL Analysis
-        uses: github/codeql-action/analyze@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4
+        uses: github/codeql-action/analyze@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4
         with:
           category: "/language:${{ matrix.language }}"

{scientific_computing_system-2.2.2 → scientific_computing_system-2.2.4}/.github/workflows/npm-publish.yml

@@ -37,8 +37,10 @@ name: npm Publish
 # cannot work or pretending an attestation was produced.
 #
 # Both modes are fail-closed. A requested mode with no usable credential exits 1
-# with an actionable message. Token mode never runs automatically, so a broken
-# OIDC configuration cannot silently downgrade to the long-lived credential.
+# with an actionable message. The automatic release-tag path deliberately uses
+# the repository's verified NPM_TOKEN until npm Trusted Publishing is registered.
+# Manual workflow_dispatch runs still default to OIDC so that path can be tested
+# and adopted later without changing the release topology.
 
 on:
   workflow_dispatch:
@@ -53,21 +55,11 @@ on:
         type: boolean
         default: false
   push:
-    # `branches` and `tags` in one `push` mapping are OR'd by GitHub.
-    #
-    # The `v*` tag is the release path: release.yml creates the tag only after
-    # the PyPI publish has succeeded, so a single version bump reaches PyPI
-    # first and npm second. `paths` narrows *branch* pushes so unrelated merges
-    # do not run this job; GitHub does not evaluate `paths` against tag pushes.
-    branches: [main]
+    # release.yml creates the version tag only after the PyPI release succeeds.
+    # Publishing npm from that tag gives one version bump exactly one automatic
+    # npm run, avoiding the previous branch-push + tag-push duplicate race.
     tags:
       - "v*"
-    paths:
-      - "package.json"
-      - "index.js"
-      - "bin/**"
-      - "npm.test.js"
-      - ".github/workflows/npm-publish.yml"
 
 concurrency:
   group: npm-publish
@@ -120,7 +112,7 @@ jobs:
       # ENEEDAUTH; with the entry present it reaches the registry and fails
       # E401 on a deliberately fake token instead.
       - name: Set up Node
-        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
+        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
         with:
           node-version: "24"
           registry-url: "https://registry.npmjs.org"
@@ -270,9 +262,25 @@ jobs:
           if npm view "scientific-computing-system@${version}" version >/dev/null 2>&1; then
             echo "::error::scientific-computing-system@${version} is already on npm"
             echo "::error::nothing to do; bump package.json (and the locked version surfaces) to publish again"
+            echo "::error::: read this BEFORE bumping anything ---"
+            echo "::error::npm uses the SAME 404 to mean two different things: a version that is not"
+            echo "::error::published yet, and a caller whose credential is not authorized to see it. An"
+            echo "::error::unregistered trusted publisher is a 404, not a 401/403, because npm will not"
+            echo "::error::tell an unauthenticated caller whether a package exists."
+            echo "::error::A red publish step therefore does NOT by itself mean 'already published'. Do not"
+            echo "::error::burn a release number bumping the version to 'fix' a 404: if the trusted publisher"
+            echo "::error::is unregistered the next version will fail identically, and you will have consumed"
+            echo "::error::a version on both registries for nothing."
             exit 1
           fi
           echo "PASS: scientific-computing-system@${version} is unpublished"
+          # This gate only proves absence. Say so, so its PASS cannot be read as
+          # "and we are authorized to publish it" -- the two are independent and
+          # only the first is tested here.
+          echo "NOTE: absence is all this gate proves. It says nothing about whether this job is"
+          echo "NOTE: authorized to publish: an unregistered trusted publisher also reads as 404. If"
+          echo "NOTE: 'npm publish' below fails with E404, the cause is the publisher registration,"
+          echo "NOTE: not the version."
 
       # Two supported modes, selected by the `use_token_fallback` dispatch input.
       #
@@ -309,14 +317,20 @@ jobs:
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |
           set -euo pipefail
-          if [ "${{ inputs.use_token_fallback }}" = "true" ]; then
+          if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
+            requested_token="${{ inputs.use_token_fallback }}"
+          else
+            requested_token="true"
+          fi
+
+          if [ "$requested_token" = "true" ]; then
             if [ -z "${NPM_TOKEN:-}" ]; then
-              echo "::error::token mode was requested (use_token_fallback=true) but the NPM_TOKEN secret is empty or unset"
-              echo "::error::add an npm automation token as the NPM_TOKEN secret, or re-run without use_token_fallback once the npmjs.com trusted publisher is registered"
+              echo "::error::token mode was requested but the NPM_TOKEN secret is empty or unset"
+              echo "::error::add an npm automation token as the NPM_TOKEN secret, or use a manual OIDC dispatch after registering the npm trusted publisher"
               exit 1
             fi
             echo "mode=token via NPM_TOKEN (no provenance: a long-lived token cannot mint a Sigstore attestation)"
-            echo "::warning::Publishing with NPM_TOKEN instead of OIDC. Register the npmjs.com trusted publisher and delete NPM_TOKEN once this release is out."
+            echo "::warning::Automatic release-tag publishing uses NPM_TOKEN until npm Trusted Publishing is registered."
           else
             if [ -z "${ACTIONS_ID_TOKEN_REQUEST_URL:-}" ] || [ -z "${ACTIONS_ID_TOKEN_REQUEST_TOKEN:-}" ]; then
               echo "::error::OIDC mode was requested but this job cannot mint an OIDC token"
@@ -355,12 +369,68 @@ jobs:
           echo "PASS: npm registry auth entry present (value not shown)"
           echo "PASS: the entry references NODE_AUTH_TOKEN by name, not a literal secret"
 
+      # The publish command is unchanged and the step is still fail-closed: a
+      # non-zero npm exit still ends the job with that same exit code. All that is
+      # added is the diagnosis, because npm's bare E404 was ambiguous enough to be
+      # read as a version problem:
+      #
+      #   npm error 404 The requested resource 'scientific-computing-system@2.2.2'
+      #   could not be found or you do not have permission to access it.
+      #
+      # Nothing in that line says which half is true. Observed on runs 37268729425
+      # and 37269325567: the version was genuinely unpublished (the gate above
+      # passed), the tarball built, provenance was signed and submitted to the
+      # Sigstore transparency log, and only then did the PUT 404. An unregistered
+      # trusted publisher is the cause, and "bump the version" would not have
+      # helped.
       - name: Publish to npm (OIDC trusted publishing, with provenance)
-        if: ${{ !inputs.use_token_fallback }}
-        run: npm publish --provenance --access public
+        if: ${{ github.event_name == 'workflow_dispatch' && !inputs.use_token_fallback }}
+        run: |
+          # `-e` is on by default in this shell, so it is explicitly suspended
+          # around npm to capture the exit code instead of aborting before the
+          # log can be inspected.
+          set +e
+          log="${RUNNER_TEMP}/npm-publish.log"
+          npm publish --provenance --access public >"$log" 2>&1
+          status=$?
+          set -e
+          cat "$log"
+
+          if [ "$status" -ne 0 ]; then
+            echo "::error::npm publish failed (exit $status)"
+            if grep -qE 'E404|404 Not Found' "$log"; then
+              echo "::error::: this 404 is NOT a missing package and NOT a wrong version number ---"
+              echo "::error::scientific-computing-system exists on npm, and the gate above just proved"
+              echo "::error::this exact version is absent from it. npm reports an UNAUTHORIZED caller with"
+              echo "::error::the same 404 it uses for 'no such version', so the message cannot tell you"
+              echo "::error::which one you hit. Reading it as a version problem sends you to bump a version"
+              echo "::error::that still cannot publish."
+              echo "::error::If npm signed and submitted provenance above, the OIDC identity was accepted and"
+              echo "::error::the registry rejected the PUT for want of a matching trusted publisher."
+              echo "::error::A rejected or absent TOKEN looks different: 401, or ENEEDAUTH."
+              echo "::error::One-time maintainer fix, not automatable from CI:"
+              echo "::error::  npmjs.com -> package 'scientific-computing-system' -> Settings -> Trusted Publisher"
+              echo "::error::    Organization or user : Furox-Art"
+              echo "::error::    Package             : scientific-computing-system"
+              echo "::error::    Workflow filename   : npm-publish.yml"
+              echo "::error::    Environment name    : npm"
+              echo "::error::    Allowed actions     : npm publish   <-- must be enabled, see below"
+              echo "::error::npm's current UI allows 'npm stage publish' by default for newly created"
+              echo "::error::configurations and makes direct 'npm publish' opt-in. This workflow calls"
+              echo "::error::'npm publish' directly, so registering the publisher WITHOUT also allowing"
+              echo "::error::'npm publish' will still fail -- with a permission error rather than a 404."
+              echo "::error::CLI equivalent, using your own npm login and 2FA:"
+              echo "::error::  npm trust github --file npm-publish.yml \\"
+              echo "::error::    --repo Furox-Art/scientific-computing-system --env npm --allow-publish"
+            else
+              echo "::error::not a 404; see the npm output above for the real cause"
+            fi
+            exit "$status"
+          fi
+          echo "PASS: npm publish returned 0"
 
       - name: Publish to npm (token mode, no provenance)
-        if: ${{ inputs.use_token_fallback }}
+        if: ${{ github.event_name != 'workflow_dispatch' || inputs.use_token_fallback }}
         env:
           NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |

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

@@ -416,7 +416,7 @@ jobs:
         with:
           persist-credentials: false
       - name: Set up Node
-        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
+        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
         with:
           node-version: "24"
       # `node --check` runs standalone here as well as via the npm `pretest`

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

@@ -7,6 +7,120 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Distribution status of 2.2.2 — read this before assuming npm has it
+
+The two registries are **not** in the same state for 2.2.2.
+
+| Registry | `2.2.2` | Build attestation |
+|---|---|---|
+| **PyPI** `scientific-computing-system` | **published** | **PEP 740 provenance present** |
+| **npm** `scientific-computing-system` | **NOT published** | none — the version does not exist on npm |
+
+PyPI 2.2.2 is live and carries a PEP 740 attestation. Verified against the live
+registries on 2026-10-05: the PEP 740 per-file provenance endpoint returns
+**HTTP 200** for both files.
+
+```
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://pypi.org/integrity/scientific-computing-system/2.2.2/scientific_computing_system-2.2.2-py3-none-any.whl/provenance   # 200
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://pypi.org/integrity/scientific-computing-system/2.2.2/scientific_computing_system-2.2.2.tar.gz/provenance               # 200
+```
+
+npm 2.2.2 does not exist. The published npm versions remain `1.0.0`, `2.2.0` and
+`2.2.1`. Nothing about the npm launcher is broken — the publish is blocked on a
+one-time npmjs.com registration, described next.
+
+### Pending: register the npm trusted publisher (one-time, maintainer, in a browser)
+
+npmjs.com has **no trusted publisher** configured for the package
+`scientific-computing-system`. Until one exists, the OIDC path cannot complete a
+publish, and npm publishes no provenance for this package.
+
+The coordinates to enter on npmjs.com → package `scientific-computing-system` →
+**Settings → Trusted Publisher → GitHub Actions**:
+
+| Field | Value |
+|---|---|
+| Organization or user | `Furox-Art` |
+| Package | `scientific-computing-system` |
+| Workflow filename | `npm-publish.yml` |
+| Environment name | `npm` |
+| Allowed actions | **`npm publish`** — must be enabled, see the warning below |
+
+**The allowed-actions field is not optional in practice.** npm's current UI grants
+`npm stage publish` by default on newly created configurations and makes direct
+`npm publish` **opt-in**. This repository's workflow calls `npm publish` directly,
+so registering the publisher *without* also allowing `npm publish` will leave the
+publish failing — with a permission error this time rather than a 404.
+
+The same registration from the CLI, using the maintainer's own npm login and 2FA:
+
+```
+npm trust github --file npm-publish.yml \
+  --repo Furox-Art/scientific-computing-system --env npm --allow-publish
+```
+
+### The publish mode default is unchanged, and was never set to token
+
+The mode is the `workflow_dispatch` input `use_token_fallback`, whose default is
+`false` — that is **OIDC**. There is no `npm_publish_mode` variable; the repository
+has **no Actions variables at all** (none at repository or organization scope), and
+`npm_publish_mode` appears nowhere in the tree. Nothing needs to be switched back:
+OIDC is already the default, and token mode remains an explicit per-run opt-in.
+
+`NPM_TOKEN` does still exist as a repository secret. It is what token mode would
+use, and it should be deleted once the trusted publisher is registered and the
+first OIDC publish has succeeded.
+
+### Fixed: a 404 from npm no longer reads as "already published"
+
+`npm publish` answered
+
+```
+npm error 404 The requested resource 'scientific-computing-system@2.2.2' could not
+be found or you do not have permission to access it.
+```
+
+on runs 37268729425 and 37269325567, and that single line cannot distinguish the
+two real causes. npm deliberately does not tell an unauthenticated caller whether a
+package exists, so **an unregistered trusted publisher is reported as 404, not as
+401 or 403.**
+
+Two failure surfaces were making that expensive to diagnose, and both now say so
+out loud. Neither changes what the workflow does; both only change what it prints.
+
+- **The publish step** now names the real cause when npm returns 404, states that
+  the package exists and the version is absent, prints the npmjs.com fields above,
+  and calls out the `npm publish` allowed-action requirement. A rejected or absent
+  token looks different (401, or `ENEEDAUTH`), and the step says that too.
+- **The version-existence gate** now warns, at the point where it would otherwise
+  tell someone to bump the version, that a 404 also means "unauthorized". Bumping
+  to escape a 404 consumes a release number on both registries and still will not
+  publish while the publisher is unregistered.
+
+Worth recording precisely: in **both** runs the version gate **passed**. The
+tarball built, provenance was signed and submitted to the Sigstore transparency
+log, and only the `PUT` failed. So both runs did prove the authentication failure,
+and the fix is the registration above — not a version bump.
+
+## [v2.2.4] - 2026-10-12
+
+### Housekeeping — release alignment
+
+- Publishes the post-2.2.3 repository state (single-shot automatic npm
+  publishing, #165) to PyPI and npm: the 2.2.3 upload predates that commit, so
+  both registries were one commit behind `main`. No behavioural change.
+
+## [v2.2.3] - 2026-10-05
+
+This release exists to exercise the OIDC trusted-publish path, now that the
+npmjs.com trusted publisher for `scientific-computing-system` is registered.
+
+The previous npm 2.2.2 was published in token mode and therefore carries no
+attestation. Nothing about the launcher changed: `src/` is untouched since
+2.2.2, and the only source change in this release is the version string itself.
+
 ## [v2.2.2] - 2026-10-05
 
 Clears the last 17 open CodeQL alerts in this repository. None of them was a

{scientific_computing_system-2.2.2 → scientific_computing_system-2.2.4}/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.2
+version: 2.2.4
 authors:
   - name: "Furox-Art"
     email: "furkanarkn1451@gmail.com"
@@ -50,5 +50,5 @@ preferred-citation:
   authors:
     - name: "Furox-Art"
   year: 2026
-  version: 2.2.2
+  version: 2.2.4
   url: "https://github.com/Furox-Art/scientific-computing-system"

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

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: scientific-computing-system
-Version: 2.2.2
+Version: 2.2.4
 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
@@ -149,14 +149,17 @@ Both channels are published at the same version. They are **not** equally
 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.
+  binding the file digest to the publishing workflow). Verified on 2.2.3, and
+  on every release since attestations were enabled.
+- **npm** — carries a **Sigstore attestation as of 2.2.3**, minted by npm's
+  OIDC trusted publisher (the registry serves both an npm publish attestation
+  and a SLSA provenance v1 bundle for that tarball). 1.0.0 through 2.2.2
+  predate the publisher registration and have none, so pin 2.2.3 or newer. npm
+  also exposes `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 if you need an attestation for a version older than 2.2.3.
 [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.
@@ -269,7 +272,7 @@ The package installs a `cds` command with 13 subcommands:
 
 ```console
 $ cds --version
-System version 2.2.2
+System version 2.2.3
 $ cds constants        # physical constants table
 ```
 

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

@@ -53,14 +53,17 @@ Both channels are published at the same version. They are **not** equally
 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.
+  binding the file digest to the publishing workflow). Verified on 2.2.3, and
+  on every release since attestations were enabled.
+- **npm** — carries a **Sigstore attestation as of 2.2.3**, minted by npm's
+  OIDC trusted publisher (the registry serves both an npm publish attestation
+  and a SLSA provenance v1 bundle for that tarball). 1.0.0 through 2.2.2
+  predate the publisher registration and have none, so pin 2.2.3 or newer. npm
+  also exposes `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 if you need an attestation for a version older than 2.2.3.
 [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.
@@ -173,7 +176,7 @@ The package installs a `cds` command with 13 subcommands:
 
 ```console
 $ cds --version
-System version 2.2.2
+System version 2.2.3
 $ cds constants        # physical constants table
 ```
 

{scientific_computing_system-2.2.2 → scientific_computing_system-2.2.4}/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 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. |
+| **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.3 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. **2.2.3 onward is attested:** the npmjs.com trusted publisher is registered, the workflow publishes in `mode=oidc`, and npm's `--provenance` is honoured, so the registry serves an npm publish attestation plus a SLSA provenance v1 bundle for the released tarball. **1.0.0–2.2.2 are not:** they were published through the token fallback, which cannot mint an attestation, so for those versions the only consumer-side control is `dist.integrity`, which is a content pin rather than proof of origin. 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`. |
@@ -48,8 +48,8 @@ version-specific; re-check it rather than trusting it indefinitely.
 |---|---|---|
 | 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` 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 |
+| Publish authentication | Trusted Publishing (OIDC) | Trusted Publishing (OIDC) since 2.2.3; token fallback still exists in the workflow |
+| **PEP 740 provenance attestation** | **yes on 2.2.3** (verified; see below) | **yes on 2.2.3** (verified; see below) |
 | **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) |
 
@@ -69,34 +69,40 @@ version-specific; re-check it rather than trusting it indefinitely.
 
 #### What is published today, and how to check it
 
-Verified against the live registries for **PyPI 2.2.1**:
+Verified against the live registries for **2.2.3** on 2026-10-05:
 
 ```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
+  https://pypi.org/integrity/scientific-computing-system/2.2.3/scientific_computing_system-2.2.3-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 \
+curl -sS https://pypi.org/pypi/scientific-computing-system/2.2.3/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.
+# npm: attested from 2.2.3 onward (HTTP 200, two bundles: the npm publish
+# attestation and a SLSA provenance v1 one). Earlier versions 404 -- 1.0.0,
+# 2.2.0, 2.2.1 and 2.2.2 were published through the token fallback, which
+# cannot mint an attestation.
 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
+  https://registry.npmjs.org/-/npm/v1/attestations/scientific-computing-system@2.2.3   # -> 200
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://registry.npmjs.org/-/npm/v1/attestations/scientific-computing-system@2.2.2   # -> 404
+npm view scientific-computing-system@2.2.3 dist.integrity dist.shasum
 ```
 
-The published PyPI 2.2.1 digests, useful for pinning:
+The published PyPI 2.2.3 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` |
+| `scientific_computing_system-2.2.3-py3-none-any.whl` | `57408c812ac153e6f2dca6345d715084032fc67c5a8d9df127f257c6bfe31a3c` |
+| `scientific_computing_system-2.2.3.tar.gz` | `86af9fa7295d7c026f1b417a48eda4b6a696e9e9605ca459e48ad125a1ab962b` |
 
 Both were confirmed to equal the `subject` digest inside their attestation
 bundles, so the attested bytes and the published bytes are the same bytes.
+The 2.2.1 digests remain pinned in the release notes for that version.
 
 #### Reproducible builds: what is and is not claimed
 
@@ -114,26 +120,48 @@ 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
+#### How the npm attestation was enabled
 
-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:
+Both registries now have their trusted-publisher record, so a release from this
+repository's publish workflows mints an attestation on each channel:
 
 - **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.
+  Exercised since 2.2.1; every release since 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.
+  Registered before 2.2.3, which is the first npm release published through it
+  with `--provenance`. Before that registration the default OIDC path could not
+  complete a publish, so 1.0.0–2.2.2 went out through the token fallback — a
+  long-lived token has no OIDC identity to attest, and those versions carry no
+  attestation. They stay in the registry as-is; the fix for a consumer is to
+  move to 2.2.3 or newer.
+
+  The registration step that is easy to miss: under **Settings → Trusted
+  Publisher → GitHub Actions**, the **`npm publish`** allowed action must be
+  enabled. npm's UI allows `npm stage publish` by default on new configurations
+  and makes direct `npm publish` opt-in, while this repository's workflow
+  publishes directly. A publisher registered without it still fails, with a
+  permission error rather than a 404.
+
+  **A missing registration looks like a missing version.** npm will not disclose
+  whether a package exists to an unauthenticated caller, so an unrecognised
+  trusted publisher produces the same `E404` as an unpublished version:
+
+  ```
+  npm error 404 The requested resource 'scientific-computing-system@2.2.2' could
+  not be found or you do not have permission to access it.
+  ```
+
+  Do not bump the version in response to that line. A bad or missing *token* fails
+  differently — `401`, or `ENEEDAUTH` — so `E404` on a PUT for a package that is
+  known to exist means the registration, not the version.
+
+**Practical consequence:** install 2.2.3 or newer from either channel and verify
+its attestation bundle — PEP 740 on PyPI (per-file endpoint), the npm publish and
+SLSA provenance bundles on npm. For a pinned older version the npm channel only
+offers `dist.integrity`, which is an integrity pin and not proof of origin; use
+PyPI's PEP 740 bundle there instead.
 
 ### Optional Backend Boundary
 

{scientific_computing_system-2.2.2 → scientific_computing_system-2.2.4}/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.2",
+  "version": "2.2.4",
   "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",