v0.6.0

This is a security-hardening release. Since v0.5.0, nr_vault has closed a set of real access-control, secret-exposure, and outbound-request gaps and made the audit log genuinely tamper-evident — the work that takes the extension from "functional" to "trustworthy with production secrets."

Heads-up — breaking changes. Writing a secret now enforces authorization, and the Secret entity is immutable. If you call the vault API directly, review the upgrade notes below. These are intentional under the 0.x line; a 1.0 API-stability commitment comes later.

Why upgrade

Secrets are now access-controlled on write

Storing or overwriting a secret is authorized like every other operation. Previously, any backend user who could edit a record carrying a vault field could create or overwrite any vault entry, sidestepping per-secret permissions. Writes are now checked, denied attempts are audited, and non-admin users can no longer reassign ownership. A new write-groups tier lets you grant write access separately from read.

The audit log is tamper-evident

Audit entries are chained with a keyed HMAC, so after-the-fact edits or deletions in the log table are detectable rather than silent. Master-key rotation now writes start/end audit entries, and read-logging can be pinned in filesystem config so a compromised admin can't quietly switch it off from the backend.

Outbound requests can't be turned against your network

The secure HTTP client blocks requests to private, loopback, link-local, CGNAT, and cloud-metadata addresses regardless of host configuration — including the IPv6 transition forms (6to4, Teredo, IPv4-mapped) that are easy to miss — with a documented opt-back-in for on-prem deployments that genuinely need an internal host.

Secrets stay out of logs and traces

Plaintext secrets, master keys, DEKs, and OAuth tokens are marked sensitive across the crypto, DTO, and audit boundaries, so they no longer surface in stack traces, error handlers, or debug dumps. Per-secret change-detection checksums are now keyed, so identical secrets no longer produce identical checksums.

Operational niceties

A vault health probe in the backend overview surfaces master-key and configuration readiness at a glance, audit-log export is memory-bounded for large logs, and OAuth refresh-token write-back is crash-safe.

Upgrade notes

• store() enforces authorization. Callers without create/write permission now get an AccessDeniedException (and an access_denied audit entry) where the call previously succeeded. CLI, scheduler, and API actors are unaffected.
• Secret is immutable (readonly). Mutating it in place no longer works; use the with…() methods, which return a new instance.
• New database schema (write-groups table + column). Run the database comparator / extension setup after upgrading.

Full technical detail — every change with rationale — is in the CHANGELOG.

Installation

composer require netresearch/nr-vault

Publication status

• TER: extensions.typo3.org/extension/nr_vault — 0.6.0 verified
• Packagist: packagist.org/packages/netresearch/nr-vault — 0.6.0 verified
• Documentation: docs.typo3.org/p/netresearch/nr-vault/0.6/en-us/ — render verified

Security

All release artifacts are signed with Sigstore keyless signing.

Verify signatures

# Verify the release archive (requires cosign)
cosign verify-blob \
  --bundle nr-vault-0.6.0.tar.gz.sigstore.json \
  --certificate-identity-regexp 'https://github.com/netresearch/t3x-nr-vault/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  nr-vault-0.6.0.tar.gz

Provenance

This release was built and published by GitHub Actions with full SLSA provenance. Every artifact (archive, SBOM, checksums) carries a Sigstore bundle proving it originated from this repository's release workflow.