v3.0.17

• Security: bump cryptography 46.0.7 → 48.0.1 to clear GHSA-537c-gmf6-5ccf
  (vulnerable OpenSSL bundled in the cryptography wheels; availability
  impact). This required bumping sigstore 4.2.0 → 4.3.0 (within the existing
  >=4.0.0,<5.0.0 pin), which lifts the transitive cryptography <47 cap.
  sigstore 4.3.0 also permits tuf <8, allowing tuf 6.0.0 → 7.0.0 — which
  resolves the previously acknowledged GHSA-qp9x-wp8f-qgjj. That
  acknowledgement has been dropped from .security-config.toml and
  SECURITY.md regenerated. Lock recompiled and refreshed to latest in-range
  versions (certifi, idna, rich also moved) so it stays bit-reproducible.
• Replace the --unsafe-untagged flag with --no-verify, now available on
  ./init, ./deploy, and ./deploy-all (previously --unsafe-untagged was
  on ./deploy only). The old flag merely tolerated a non-release HEAD while
  still verifying signatures whenever a tag was present; --no-verify skips
  release signature verification entirely. It is a development-only override and
  prints a single loud audit banner once per run.
• install_python_packages is now silent on the happy path — output appears
  only when a dependency (re)install is actually needed.
• Add bedrock:* to the example developer permission boundary and the matching
  DeveloperAccess SSO permission set.

Full Changelog: v3.0.16...v3.0.17

v3.0.16

• Bump pyjwt 2.12.1 → 2.13.0 (transitive via sigstore), clearing
  PYSEC-2026-175, PYSEC-2026-177, PYSEC-2026-178, and PYSEC-2026-179.
  Lock refreshed to latest in-range versions (certifi, idna, platformdirs,
  requests, securesystemslib also moved) so it stays bit-reproducible.
• Acknowledge GHSA-qp9x-wp8f-qgjj against tuf (transitive via sigstore).
  The fix is tuf 7.0.0, but it is not installable: the latest sigstore
  (4.2.0, the pinned version) hard-caps tuf~=6.0 (<7.0) and no sigstore
  release yet permits tuf 7.0. The flaw is a Windows-only TUF delegation
  path-matching case-sensitivity bug (CVSS 3.1 base ~3.3, Low); tuf is used
  read-only by sigstore for release verification and the Installer runs
  customer-side on POSIX Python 3.12. Recorded in .security-config.toml, to be
  dropped once sigstore permits tuf 7.0; SECURITY.md §12 regenerated.

Full Changelog: v3.0.15...v3.0.16

v3.0.15

• init.py self-heals stale customer clones. The per-repo update path in
  clone_repo previously did git pull --quiet with stderr swallowed; any
  non-pristine local state (detached HEAD, wrong branch, divergent or recreated
  remote history) would silently leave the clone where it started and the
  subsequent _verify_release.py check would refuse with a confusing "declares
  itself converted but no Release exists" or "not yet signed" message. The new
  _resync_existing_clone helper does git fetch -p -P origin (prunes stale
  local tags so they can't shadow remote ones in git describe --tags --exact-match HEAD) followed by git reset --hard origin/main — a single
  move that handles stale, detached, wrong-branch, divergent, and
  recreated-remote uniformly. A dirty working tree is the one state that's
  refused with a specific actionable message rather than auto-healed. End-state
  assertion confirms HEAD lands on a release tag and surfaces it (Changes (vX.Y.Z) / No changes (vX.Y.Z)) so the customer can see which tagged
  release they're now on.
• install_python_packages() gains a verbose parameter. The Installer
  self-call at the top of main() still prints the full pinned-deps listing
  once; per-repo calls in clone_repo collapse to a single-line Pinned, hash-verified deps already installed ✓ confirmation on the (almost always
  taken) fast path. If a per-repo call ever needs to actually reinstall, the
  full listing prints so the reinstall isn't invisible.

Full Changelog: v3.0.14...v3.0.15

v3.0.14

• Acknowledge PYSEC-2025-183 / CVE-2025-45768 against pyjwt (transitive
  via sigstore). The advisory is disputed by the supplier — the alleged "weak
  encryption" concerns the JWT signing-key length, which is chosen by the
  consuming application rather than the library, and the Installer does not sign
  JWTs (pyjwt is used read-only by sigstore to verify Rekor/Fulcio responses
  during release verification). All pyjwt versions are listed as affected and
  no fix version is published. Recorded in .security-config.toml;
  SECURITY.md §12 regenerated.

Full Changelog: v3.0.13...v3.0.14

v3.0.13

• README.md gains the OpenSSF Best Practices Passing-level badge (project
  entry
  bestpractices.dev/projects/12827).

Full Changelog: v3.0.12...v3.0.13

v3.0.12

• Libraryless conversion path. publish.zsh now auto-detects components with no
  Python library dependencies (zero requirements.in files under the repo,
  excluding the usual non-source dirs) and emits a deterministic git archive HEAD source archive plus a SLSA Build L1 in-toto provenance attesting to it,
  both Sigstore-signed. Repos with .in files continue to use the existing SBOM
  • evidence + provenance path — backward compatible, no change for the 12
    originally converted repos. Detection is filesystem-based; no config flag
    needed. Documented in convert-component skill under "Procedure (libraryless
    repos)".
• STRICT_VERIFICATION = True in _verify_release.py. Phase 10 closed on
  2026-05-13 — every repo in apps/foundation/repos.toml and
  apps/soar/repos.toml now ships signed releases. The "skipped, work in
  progress" banner path is gone; a converted release without signed bundles now
  fails closed.
• _verify_release.py uses .security-config.toml presence on the local
  checkout as the "expect signed bundles" signal. A converted repo (config file
  present) whose remote release has no .bundle assets is flagged as a
  downgrade attack (release stripped after signing) and refuses to proceed —
  independent of STRICT_VERIFICATION.

Full Changelog: v3.0.11...v3.0.12

v3.0.11

• Security: customer-side release verification, three layers deep. A new shared
  scripts/_verify_release.py module is the single source of truth for the
  trust anchor (peter@peterbengtson.com via https://github.com/login/oauth),
  the public org (OpenSecOps-Org), the STRICT_VERIFICATION toggle, and the
  verifier itself. Distributed by refresh to every converted component so both
  Installer (init.py) and components (deploy.py) call the same function. To
  rotate the trust anchor, edit one file and ship an Installer release.
• Layer 1 — Installer self-verification at init time (closes the bootstrap
  gap). After pip install --require-hashes finishes, init.py calls
  verify_release("Installer", repo_dir=_installer_root()). A customer who has
  just pulled a tampered Installer is caught here before any component is
  touched. (TOFU applies only to first ever install; every subsequent git pull
  of Installer is verified.)
• Layer 2 — Eager component verification at init time. After each
  clone_repo() of an OpenSecOps component, init.py immediately verifies the
  cloned/updated tree. Problems surface at init rather than waiting until
  deploy. The list of failed components is summarised at the end of init so the
  customer knows where not to run ./deploy.
• Layer 3 — Just-in-time verification at deploy time. scripts/deploy.py
  calls verify_release(repo_name) after git pull, before any sam build /
  cfn deploy / script execution. Tampered artefacts, wrong signer, or missing
  bundles fail the deploy.
• Implementation: pure Python via the sigstore package (added to
  requirements.in, pinned >=4.0.0,<5.0.0). Installed by the existing pip install --require-hashes step. No new customer-side tooling required (no
  cosign, no Go runtime, no OIDC dance — verification is read-only against
  public Sigstore infrastructure).
• Behaviour during the rolling Phase 10 conversion: components without a signed
  GitHub Release print a yellow "verification is skipped for now as the repo has
  not yet been signed. This is a work in progress; we will complete it in a day
  or two, no more." banner and the caller proceeds. Once every OpenSecOps-Org
  repo ships signed releases, STRICT_VERIFICATION in _verify_release.py
  flips to True and the skip path disappears.
• New --unsafe-untagged flag on ./deploy: prints a loud red audit banner
  (OVERRIDE: deploying <repo> at untagged commit <sha> by <$USER>) and
  proceeds without verification. Intended for emergencies; not for routine use.
• Distributed to all 12 converted components via ./refresh --dev --push; each
  re-releases independently to carry the new verifying deploy.py +
  _verify_release.py.

Full Changelog: v3.0.10...v3.0.11

v3.0.10

• Tooling: compile-requirements.sh now accepts --upgrade and
  --upgrade-package PKG (repeatable) flags, plumbed through to uv pip compile. Previously the script only used existing locks as preferences, which
  meant any package with a newer in-range release on PyPI since the last compile
  would cause the release-gate's reproducible mode (clean cache, no preferences)
  to report drift and refuse to publish. Maintainers can now run
  ./compile-requirements --upgrade to refresh every lock, or
  ./compile-requirements --upgrade-package urllib3 for a minimum-change CVE
  patch. Active mode is surfaced in the banner (uv args: --upgrade-package urllib3). Distributed to all converted components via refresh; available on
  each component's next release cycle.

Full Changelog: v3.0.9...v3.0.10

v3.0.9

• Security: bump urllib3 floor to >=2.7.0 in canonical templates/boto3.in
  to remediate CVE-2026-44431 and CVE-2026-44432 (both affect urllib3 ≤ 2.6.3,
  fixed in 2.7.0). boto3==1.42.94 previously resolved urllib3 transitively to
  2.6.3 across the fleet; the new floor forces resolution to 2.7.0 in every
  component that imports boto3.in. Distributed via refresh to all
  components; each component re-releases independently with recompiled locks.
• Installer's own requirements.txt recompiled (urllib3 → 2.7.0); no code
  changes.

Full Changelog: v3.0.8...v3.0.9

v3.0.8

• Enable auto-close workflow for external pull requests, enforcing the cathedral
  governance policy uniformly across all OpenSecOps repositories. Pull requests
  from non-team authors are closed automatically with a redirect comment
  pointing to the bug-report template, the GitHub Security Advisory flow, and
  the fork-under-MPL-2.0 path. Distributed by refresh to all components.
• SECURITY.md.template §14 now carries a Trust-page cross-link
  (opensecops.org/trust.html) alongside
  the existing canonical supply-chain document link, positioning the Trust page
  as the lighter customer-facing synthesis. Installer's own SECURITY.md
  regenerated to match; distributed to all components via refresh and rendered
  on each component's next publish.

Full Changelog: v3.0.7...v3.0.8