Skip to main content
Core 0.4.1 is published for Rust, Python, Node.js, and browser WASM. All four runtimes passed clean registry-installed verification. See the GitHub release.

Release provenance

The release source is 175e67548f654c740352a7d909ae55d376dfcb0d. All four runtime packages are published at version 0.4.1. The Rust registry consumer verified capability contract 1, the 23/14 inventory, all three credential detectors, Unicode byte/code-point ranges, explicit-label redaction, and unsupported-locale rejection. Its Cargo.lock resolved crates.io with checksum 25b0893bd983973d65793f6406f18e0b1da30f1996148996813758b16ea20b29. The Python workflow published five platform wheels and a source distribution. The clean PyPI macOS ARM64 wheel passed installed binding and typing checks, pip check, all 352 adapter regression tests against adapter source e31e9e5dd97581622515a97e4421dc558828e706, and the portable 10-fixture, 60-transformation overlap audit. Frozen parity remained unchanged. The browser WASM npm installation passed all ten conformance helpers in Chromium, including 23/14 inventory parity and detectorVersion: 0.4.1. The Node.js registry installation passed all ten conformance helpers using the native binding on Node 24. Checks covered 23/14 scan inventory parity, structured PERSON, German and UUID opt-ins, and detectorVersion: 0.4.1. The npm lockfile confirmed registry provenance without a local package archive. Publishing workflows: Rust, Python, Node.js, and browser WASM.

New default detectors

Core 0.4.1 adds three labels to ordinary text and structured scanning, without changing capability contract version 1. The runtime registry now reports 23 supported entities and 14 default text detectors; the capabilities reference is generated from that registry. All bindings use the Rust implementations and preserve existing finding offsets and provenance. Locale and UUID activation rules are unchanged. These are lexical detectors. They do not authenticate credentials, contact providers, check entropy, or establish that a connection succeeds.

Provider key heuristics

API key detection recognizes case-sensitive GitHub ghp_, gho_, and ghu_ bodies of exactly 36 ASCII letters/digits; ghr_ bodies of 76; and github_pat_ bodies of 22 letters/digits, an underscore, and 59 letters/digits. Installation tokens beginning ghs_ are opaque: at least 36 letters/digits, underscores, hyphens, or periods, with no JWT decoding or segment-count requirement. A final period remains part of an otherwise valid ghs_ value. Stripe sk_test_, sk_live_, rk_test_, and rk_live_ keys require at least 24 ASCII letters/digits after the prefix. That minimum is a detector heuristic, not a provider-issued-key guarantee. Publishable keys, webhook secrets, organization keys, unprefixed strings, and other provider formats are excluded. The reference defines exact boundaries and whole-value rejection rules.

Bearer context

Bearer detection requires explicit Authorization context. Raw headers must occupy a header line; quoted JSON header entries must satisfy the documented boundaries. Structured scanning also accepts a string leaf immediately named Authorization, ignoring ASCII case, and preserves Bearer when transforming the token. Arrays under that key, sibling fields, prefixed header names, and bare Bearer TOKEN prose do not supply context. Tokens follow the RFC 6750 alphabet and terminal-padding rule.

Credential URI boundaries

Credential URI detection accepts the two PostgreSQL scheme spellings with ASCII case-insensitive matching, an explicit nonempty password, and a single supported hostname, IPv4/IPv6 host, or omitted host. Decimal ports and percent triplets are recognized lexically; port ranges and decoded credential content are not validated. Whole-URI spans preserve RFC-valid terminal punctuation, which can be ambiguous with prose. Passwordless or query-only secrets, multiple hosts, percent-encoded Unix socket hosts, fragments, raw Unicode URI content, JDBC prefixes, and other schemes remain outside this initial scope. See the detector reference for encoding and delimiter rules.

Legacy Python overlap compatibility

The Python 4.9 adapter was integrated in merged PR #179. The local candidate-wheel audit below exercises that adapter source. This Core release does not change Python’s default backend or publish the higher-level package. Its existing legacy path resolves overlaps before filtering selected labels. That order is preserved rather than introducing special priorities for the new labels. Consequently, explicit legacy entity selection can return no finding even when Core originally detected the selected label: Native Core and datafog.v5 scan results retain the overlapping candidates; native transformations apply entity selection before resolving overlaps. Callers requiring a particular label can use that native interface. The previously reviewed PHONE/NPI limitation is described in the 0.4.0 release notes.

Local exact-wheel integration result

PASS: the exact candidate wheel was installed with the actual Python 4.9 adapter in an isolated environment. Installed artifact provenance matched the expected SHA256. No functional integration failures were found. Reviewed frozen parity remained 77 matches, 2 detector differences, 1 validation difference, and 31 cases outside backend scope, with no additional deviations. The overlap audit confirmed the legacy selection differences above, exact/regex allowlists, Unicode offsets, structured Authorization context and exclusions, and locale acceptance/rejection. Python’s default backend remained Python; the new credential labels did not silently activate there.

Reproduce the local gate

Set ADAPTER_CHECKOUT to the reviewed Python adapter checkout, CORE_CHECKOUT to the matching Core conformance checkout, CORE_WHEEL to the exact wheel, PYTHON to CPython 3.12, and VENV to a fresh environment directory. The checked-in bindings/python/tests/test_python49_integration.py exercises the real installed adapter and expands the shared synthetic fixtures. It prints a summary by default; --output optionally saves detailed JSON evidence. These commands install the local wheel rather than resolving Core from a registry:
Verify the wheel SHA256 before installation and retain pip’s direct_url.json artifact provenance with the results. The wheel hash above identifies the binary actually exercised by this local gate; it is separate from registry artifact checksums. The final release source is recorded above. See the validation limits before treating this result as release readiness.

Validation limits

This result covers one local macOS ARM64 wheel on CPython 3.12.13. It does not establish cross-platform wheel compatibility, complete the Rust/Node/browser WASM gates, authorize publication, or verify registry-installed artifacts. Post-publication installation results are recorded separately above. This local evidence must not be substituted for those registry checks.