Cut 2.4.1

[oscarvalenzuelab]

Release prep. Everything already merged; this moves [Unreleased] under a version heading and bumps the version.

What 2.4.1 contains

Both halves of one problem — how a profile is found, and whether the name it is found by agrees with the name it reports.

A profile whose id and filename disagree is refused at load (#30, closes #25). Lookup resolves by filename; every finding, JSON report and SARIF run then carries the id. A file named my-policy.yaml declaring id: acme-baseline loaded under --profile my-policy and reported acme-baseline throughout, so grepping CI output for the name that was invoked found nothing. extends resolves by filename while excludes targets the id, so composition saw the same split.

The filename's spelling is confirmed on disk (#31). os.path.isfile answers the filesystem's question rather than this tool's, so Acme-Baseline.yaml declaring id: acme-baseline resolved on macOS and Windows and failed with "Profile not found" on Linux — the same overlay working on a laptop and failing in CI. That also made the check above weaker than it read: it was comparing the name that was asked for against the id rather than the name that exists.

Profile not found now explains the convention and names the file it looked for, because a correctly written overlay under the wrong filename produced a bare "not found" that sent readers hunting for a missing file.

Patch, not minor

No new surface. Two bug fixes, better error messages, and a test correction. Nothing that resolved before stops resolving, except overlays that were already failing on Linux or already reporting a name nobody invoked.

Adopter impact

An overlay whose id and filename disagree, or whose filename differs only by case, now fails to load rather than half-working. That is the intent — both were already broken, quietly or on another platform — and both messages name the file they expected.

The bundled catalog is unaffected: a parametrised test asserts all 15 profiles satisfy the rule.

Also in here

A test fix for ospac 1.7.0 (#32), which added "the apache license, version 2.0" to its aliases and moved that spelling from the descriptive-key path to the exact-alias path. Test-only — no behaviour changed, and the licence still resolves to Apache-2.0.

Checks

• pyproject.toml, src/ossbomer/__init__.py and the compare link all at 2.4.1
• 1052 tests pass with ospac 1.7.0; ruff and mypy clean
• python -m build produces both artifacts; twine check passes on each

Tagging v2.4.1 once this lands, which triggers the PyPI publish.