5 Commits

Author SHA1 Message Date
kingchenc eb50ae4e90 deps(python): upgrade pyo3 + rust-numpy to 0.29, clear 2 advisories (#295)
rust-numpy 0.29 lifted its pyo3 ^0.28 pin, so the resolver can now select
pyo3 0.29. Bump both (kept as a pair) and drop the temporary not-affected
exceptions for RUSTSEC-2026-0176 and RUSTSEC-2026-0177 from deny.toml and
osv-scanner.toml — pyo3 0.29 fixes both advisories.

No public API change; the Python test suite passes unchanged (957 tests).
2026-06-14 00:36:52 +02:00
kingchenc c3029f2548 ci(supply-chain): ignore RUSTSEC-2026-0176/0177 until rust-numpy 0.29 (#271)
## Why

`Supply-chain (cargo-deny)` started failing on every CI run from 2026-06-11
onward, including all five open Dependabot action-bump PRs (#266–#270), which
touch no Rust code. The cause is two PyO3 advisories published 2026-06-11:

| Advisory | Issue | Affected | Patched |
|----------|-------|----------|---------|
| RUSTSEC-2026-0176 | OOB read in `PyList`/`PyTuple` `nth`/`nth_back` | `>=0.24.0, <0.29.0` | `>= 0.29.0` |
| RUSTSEC-2026-0177 | Missing `Sync` bound on `PyCFunction::new_closure` | `>=0.15.0, <0.29.0` | `>= 0.29.0` |

We are on pyo3 0.28.3, so both apply.

## Why not just bump pyo3 to 0.29

The clean fix is blocked upstream: `rust-numpy` 0.28 (its latest release) hard-pins
`pyo3 ^0.28.0`, so the resolver rejects 0.29 (`failed to select a version for the
requirement pyo3 = "^0.28.0"`). rust-numpy's "Updated to PyO3 version 0.29.0" PR is
open but not yet published to crates.io.

## Why the ignore is safe

Neither vulnerable code path is reachable from our binding — verified by grep over
`bindings/python/src`: no `BoundListIterator::nth`/`nth_back` or `PyTuple`
equivalents (0176), no `PyCFunction::new_closure` (0177), zero `PyList`/`PyTuple`
references at all.

## Removal trigger

Drop both ignores once rust-numpy 0.29 lands and pyo3 is bumped to 0.29.

Verified locally: `cargo deny check` → `advisories ok, bans ok, licenses ok, sources ok`.
2026-06-12 21:38:10 +02:00
kingchenc 11dd659b5f Relicense from PolyForm Noncommercial to MIT OR Apache-2.0 (#158)
Relicenses Wickra from PolyForm Noncommercial 1.0.0 to the dual, OSI-approved **MIT OR Apache-2.0** (the de-facto Rust convention). Wickra becomes permissive, commercial-use-permitted open source; users may choose either license.

## Changes
- Replace `LICENSE` (PolyForm) with `LICENSE-MIT` + `LICENSE-APACHE` (full texts).
- Cargo: workspace `license = "MIT OR Apache-2.0"` (SPDX) + all 7 sub-crates switched from `license-file.workspace` to `license.workspace`.
- `deny.toml`: drop PolyForm from the allowlist.
- Python: `pyproject.toml` PEP 639 SPDX expression; remove the non-commercial classifier (verified: sdist metadata emits `License-Expression: MIT OR Apache-2.0`).
- Node: `package.json`, the 6 platform manifests and both lockfiles.
- README + Python/Node/WASM binding READMEs, CONTRIBUTING, CITATION.cff, PR template, and the WASM `pkg.license` step in `release.yml`.
- SECURITY.md: refresh supported versions 0.1.x -> 0.4.x.
- CHANGELOG: note the relicense under [Unreleased].

## Notes
- No code changes; metadata/text only. `cargo build` and `cargo deny check licenses` pass locally.
- GitHub will auto-detect "MIT, Apache-2.0" once this lands (currently NOASSERTION).
- Matching downstream changes (org `.github` profile, webpage, docs) are in separate PRs; merge those together with the relicense release so the live sites and org profile do not claim MIT before the packages do.
2026-06-03 18:49:39 +02:00
kingchenc c99cf54a1f fix(security): upgrade pyo3 and numpy to 0.28, fix RUSTSEC-2025-0020
Bumps the Python binding from pyo3 0.22 / numpy 0.22 to 0.28 / 0.28,
which resolves RUSTSEC-2025-0020 — a buffer overflow in
`PyString::from_object` that affected every published Python wheel.

Migration:

- `into_pyarray_bound(py)` → `into_pyarray(py)` (numpy 0.23 dropped the
  `_bound` transitional suffix; the method now returns `Bound<'py, _>`
  directly).
- `downcast::<PyDict>` → `cast::<PyDict>` (pyo3 renamed the method on
  `PyAnyMethods`).
- Every `#[pyclass]` declares `skip_from_py_object` to opt out of the
  now-deprecated automatic `FromPyObject` derive for `Clone` types.
  Indicators are stateful — silently extracting them by value-clone is
  never the intended FFI semantics.
- Workspace clippy gains `unused_self = "allow"` on the python crate
  only: Python's `__repr__` protocol forces `&self` even for parameter-
  less indicators where the body does not read state.
- `map_err` arms collapsed into a single `PyValueError` arm
  (clippy::match_same_arms).

`deny.toml` no longer suppresses RUSTSEC-2025-0020; `cargo deny check`
is green on advisories, bans, licenses and sources without exceptions.
2026-05-23 01:26:55 +02:00
kingchenc 71e46a1ea6 E10: add cargo-deny supply-chain checks
The repository had no supply-chain auditing — no deny.toml and no CI
job to catch vulnerable, unmaintained, wrongly-licensed, or
unexpectedly-sourced dependencies.

Add deny.toml covering advisories, bans, licenses and sources:

- licenses: an allow-list of the permissive licenses the dependency
  tree actually uses, plus the workspace's own PolyForm-Noncommercial
  license and a scoped LLVM-exception for target-lexicon.
- bans: warn on duplicate versions, deny external wildcard deps
  (internal path deps are allowed).
- sources: only crates.io.
- advisories: RUSTSEC-2025-0020 (pyo3 0.22) is ignored with a documented
  reason — it is reachable only through bindings/python and the pyo3
  upgrade is tracked separately; the published crates do not use pyo3.

Add a `supply-chain` CI job running cargo-deny-action (SHA-pinned).
`cargo deny check` passes locally: advisories/bans/licenses/sources ok.
2026-05-22 16:25:58 +02:00