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 is175e67548f654c740352a7d909ae55d376dfcb0d.
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 GitHubghp_, 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 namedAuthorization, 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
SetADAPTER_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:
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.