v0.10.0-rc.1

Release candidate. Closes the launch-readiness items found in the
deploy/onboarding review: the AWS/Azure/GCP passwordless onboarding
templates are runnable as documented, image tags are unified, the
extended-statistics-data collectors degrade cleanly under a
least-privilege role, the Terraform modules are validated in CI, and the
AWS aws_rds_iam path is live-validated against an IAM-auth RDS.

Added

• CI: terraform validate for the cloud onboarding modules (#202). A new
  Terraform Validate workflow runs fmt -check + init -backend=false +
  terraform validate across deploy/{aws,azure,gcp}/terraform on every PR
  that touches those modules. Backend-free, so no cloud credentials are used
  and nothing is provisioned. All three modules validate clean; the earlier
  failure was an environment-specific provider-plugin issue, not a template
  defect.
• Operator-gated AWS aws_rds_iam live-smoke workflow + runbook (#201).
  A workflow_dispatch-only AWS RDS IAM Live Smoke workflow does
  terraform apply against an IAM-auth RDS instance, transiently grants the
  collector role SSM to reach the loopback-only API, forces a collection,
  asserts a passwordless snapshot, then always terraform destroys. It is
  not part of default CI — nothing runs and no cloud cost is incurred
  until an operator dispatches it with an AWS_LIVE_SMOKE_ROLE_ARN (GitHub→AWS
  OIDC, no long-lived keys). See deploy/aws/LIVE-SMOKE.md. Azure/GCP variants
  follow the same shape (follow-up).

Changed

• Swept all deploy assets to image tag 0.10.0-beta.7 (#199). The Helm
  chart (Chart.yaml version/appVersion, values.yaml image.tag) had
  drifted to beta.6 and the Azure/GCP Terraform + Azure Bicep to beta.5;
  all now pin the smoke-tested beta.7. (AWS templates are bumped in #198.)

Fixed

• AWS onboarding templates are now runnable as documented (#198). The
  CloudFormation and Terraform templates ran the image as
  ${ImageUri} --config …, which replaced the signals CMD so tini tried to
  exec --config; they now pass the signals subcommand explicitly. User-data
  mints a control-plane API token and passes it via SIGNALS_API_TOKEN (stored
  root-only at /root/signals-api-token, outside the bind mount) so the
  documented signalsctl status / export verification can authenticate, makes
  the bind-mounted config world-readable for the non-root container, and pins the
  AWS image-tag defaults to 0.10.0-beta.7.
• Azure and GCP onboarding templates are now runnable as documented (#205).
  The Azure (Terraform + Bicep) and GCP (Terraform) templates carried the same
  defects fixed for AWS in #198: they ran the image as ${image} --config …,
  which replaced the signals CMD so tini exec'd --config; they now pass
  the signals subcommand explicitly. Cloud-init mints a control-plane API
  token and passes it via SIGNALS_API_TOKEN (stored root-only at
  /root/signals-api-token, outside the bind mount) so the documented
  signalsctl status / export verification can authenticate, and makes the
  bind-mounted config world-readable for the non-root container.
• Extended-statistics-data collectors degrade as skipped under a
  least-privilege role, and stop the repeated (incorrect) pg_monitor
  advisory (#200). pg_statistic_ext_data has PUBLIC SELECT revoked, so
  pg_statistic_ext_data_v1 / pg_statistic_ext_data_mcv_v1 return
  SQLSTATE 42501 for a pg_monitor role (the LEFT JOIN does not rescue
  it; access needs superuser or an explicit GRANT). These collectors now
  record status=skipped, reason=privilege_owner_only instead of
  failed, so the cycle is no longer reported partial for an expected
  privilege boundary. The operator advisory is corrected (the missing
  privilege is not pg_monitor) and logged once per (target, collector)
  per daemon run instead of every poll. Spec:
  specifications/owner_only_privilege_degradation.md (R116, R117);
  corrects the prior pg_statistic_ext_data_v1 FC-03 / AT-02, which
  wrongly assumed the LEFT JOIN yields available=false rows for a
  non-owner role.

---

Supply chain

• Images (same manifest digest in both registries):
  • GHCR: ghcr.io/elevarq/signals:0.10.0-rc.1
  • Docker Hub: elevarq/signals:0.10.0-rc.1 (when configured)
• Digest: sha256:83ab91a5736382eba841c5f4b18a65c463536504ce920ec9c8c401b66596f509
• Architectures: linux/amd64, linux/arm64
• Cosign-signed in both registries (keyless, GitHub OIDC)
• SBOM attached as OCI attestation and as sbom.spdx.json release asset
• SLSA build provenance attestation (mode=max)

Quick signature verification (GHCR):

cosign verify ghcr.io/elevarq/signals:0.10.0-rc.1   --certificate-identity-regexp='github.com/Elevarq/(Signals|signals)/.github/workflows/release.yml@'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Same command works against elevarq/signals:0.10.0-rc.1 — the certificate identity is bound to the workflow, not the registry.

Full verification checklist (manifest, SBOM, provenance, Trivy):
docs/release-verification.md

v0.10.0-beta.7

Highlights. Adds the AWS Systems Manager Parameter Store secret_store
backend, completes the de-arq rename to Elevarq Signals, and closes a
credential-redaction gap found during beta testing.

Breaking — first-party importers must update import paths. The Go
module path changed github.com/elevarq/arq-signals ->
github.com/elevarq/signals, and the repository was renamed
Elevarq/Arq-Signals -> Elevarq/Signals (old URLs redirect). The
deprecated arqctl / arq-signals binary aliases were removed — use
signals / signalsctl.

Security. pg_stat_statements query text is now redacted of structured
credential literals (role/user PASSWORD, libpq conninfo password=)
before persistence and export (#188).

Upgrade notes. No config changes required beyond the import-path /
binary-name renames above. The committed Chart.yaml version is stamped
from the release tag at package time, so it may lag the tag.

Added

• secret_store: AWS Systems Manager Parameter Store backend (#157).
  A target's database password may now live in Parameter Store, referenced
  by ARN (arn:aws:ssm:<region>:<acct>:parameter/<name>). The parameter is
  fetched with GetParameter and WithDecryption=true, so a SecureString
  is returned decrypted and a plain String passes through. The region is
  taken authoritatively from the ARN, and the ssm vs secretsmanager ARN
  service segment selects the backend. Requires ssm:GetParameter (plus
  kms:Decrypt on the CMK for a SecureString). All other secret_store
  behaviour (verify-full floor, no inline password, never-log, per-target
  cache, secret_json_key) is unchanged.

Changed

• Completed the de-arq rename (#171, closes #62). With the GitHub
  repository renamed to Elevarq/Signals, the last structural Arq names
  are gone: the Go module path is now github.com/elevarq/signals
  (first-party consumers must update imports), the spec tree moved
  features/arq-signals/ → features/signals/, requirement IDs are
  SIGNALS-* (was ARQ-SIGNALS-*), and residual Elevarq/Arq-Signals
  repo URLs / issue links now point at Elevarq/Signals. The deprecated
  arqctl / arq-signals binary aliases were already removed (#168).
  References to the sibling Arq analyzer repo are unchanged — that is
  a separate product.

• BREAKING — removed the residual arq branding from every user-facing
  interface (#137). Beta intentionally froze these names (see the
  beta.4 note below); with adoption beginning, this is the last window to
  rename them without a compatibility shim. There are no aliases for the
  old names — update configs, environments, and provisioning before
  upgrading. Renames:

  • Environment variables: the ARQ_SIGNALS_* prefix becomes
    SIGNALS_* (e.g. ARQ_SIGNALS_API_TOKEN -> SIGNALS_API_TOKEN,
    ARQ_SIGNALS_CONFIG -> SIGNALS_CONFIG). The two non-prefixed vars
    follow: ARQ_ENV -> SIGNALS_ENV, ARQ_ALLOW_INSECURE_PG_TLS ->
    SIGNALS_ALLOW_INSECURE_PG_TLS.
  • Default config directory: /etc/arq/ -> /etc/signals/ (default
    search path /etc/signals/signals.yaml; control-plane token default
    /etc/signals/control-plane.token).
  • Default SQLite store path: /data/arq-signals.db -> /data/signals.db.
  • PostgreSQL application_name: every collector connection now
    identifies as signals (was arq-signals); the pg_stat_activity /
    pg_stat_statements self-filter matches the new value.
  • Snapshot export schema: schema_version is now signals-snapshot.v1
    (was arq-snapshot.v1); the export metadata key arq_signals_version
    becomes signals_version. Downstream consumers of the export
    (Elevarq Analyzer/Insight) must accept the new identifier — see #137
    for the cross-repo follow-up.
  • Control-plane config: signals.mode: arq_managed -> managed;
    keys arq_control_plane_token_file / arq_control_plane_token_env ->
    control_plane_token_file / control_plane_token_env.
  • Audit-log reason value: scheduled_arq_cycle -> scheduled_cycle.
  • Documented DB monitoring role: examples now use a single signals
    role (was the inconsistent arq_signals / arq_monitor); read-only
    example role arq_signals_ro -> signals_ro.
  • Deploy/example names: Docker volume arq-data -> signals-data;
    example Kubernetes secret names arq-pg-password / arq-db-credentials
    / arq-api-token -> signals-*.

  Unchanged (tracked separately): the Go module path
  github.com/elevarq/arq-signals and the repository URL stay until the
  repository rename (#62); internal ARQ-SIGNALS-* requirement IDs are an
  internal traceability scheme. Prometheus metric names are renamed in
  the companion change below (#139).

• BREAKING — renamed the Prometheus metric prefix arq_signal_* ->
  signals_* (#139). Completes the de-arq rename for the /metrics
  endpoint surface. There are no aliases — update dashboards, recording
  rules, and alert rules before upgrading. All 14 series rename, e.g.
  arq_signal_collection_cycles_total -> signals_collection_cycles_total,
  arq_signal_circuit_state -> signals_circuit_state,
  arq_signal_export_requests_total -> signals_export_requests_total.
  Label names, label-value enums, and metric semantics are unchanged.

• Renamed the residual arq developer-facing identifiers left out of
  #137 (#150). These are internal/cosmetic names with no operator-facing
  surface, so #137 correctly scoped them out; this completes the de-arq
  rename. No behaviour change, no aliases needed (none are read by CI or
  by operators):

  • Live/integration test env vars: ARQ_TEST_* -> SIGNALS_TEST_*
    and ARQ_DOCTOR_TEST_* -> SIGNALS_DOCTOR_TEST_* (e.g.
    ARQ_TEST_PG_DSN -> SIGNALS_TEST_PG_DSN,
    ARQ_TEST_TSDB_DSN -> SIGNALS_TEST_TSDB_DSN). Set only by developers
    running the build-tag-gated live tests manually. The naming spec
    acceptance docs and features/arq-signals/traceability.md were updated
    in lockstep.
  • Transient SAVEPOINT name: the per-query savepoint is now
    signals_q_%d (was arq_q_%d); observable in pg_stat_activity /
    server logs during a collection cycle.
  • Guided-connect temp file prefix: .arqctl-connect-*.yaml ->
    .signalsctl-connect-*.yaml.
  • Sample DB usernames in test fixtures and example DSNs use the
    brand-neutral monitor (was arq).
  • Stale test names carrying the old brand were renamed
    (TestR083ArqManagedRequiresToken,
    TestR083ControlPlaneTokenSetsArqActor,
    TestHelm_ConfigMapIsMountedAtEtcArq).

  These last Arq-prefixed identifiers (the module path, the features/
  spec tree, and the requirement-ID prefix) were completed once the
  repository was renamed — see the #171 entry above.

Removed

• Deprecated binary aliases arqctl and arq-signals (#168). The old
  Arq-branded names introduced as a transitional courtesy in #62 are gone:
  the daemon and CLI no longer respond to (or warn under) those names, and
  the container image / make build no longer create the symlinks. Use
  signals and signalsctl. Brought forward from the originally planned
  post-launch removal ahead of the repository rename (#62).

Fixed

• Corrected the documented signalsctl doctor config path that pointed
  at a non-existent /etc/signals-signals/ directory (#153). The Helm
  chart mounts the ConfigMap at /etc/signals and the daemon's default
  config is /etc/signals/signals.yaml, but
  docs/install/kubernetes-production.md told operators to run
  signalsctl doctor --config /etc/signals-signals/signals.yaml, which
  fails on copy-paste — the path does not exist in the pod. The
  specifications/doctor.md example output had the same doubled directory
  (plus the wrong filename config.yaml). Both now reference
  /etc/signals/signals.yaml. The signals-signals resource names in
  the same doc are correct (Helm renders {release}-signals and the docs
  install with release name signals) and are unchanged. Documentation
  only.

• Example DB monitoring roles renamed to the single signals role
  (#141). #137's claim that the examples use a single signals role
  was incomplete — the role-creation SQL and the snapshot fixture were
  missed, leaving the bundled Docker quickstart and TimescaleDB demo
  broken (their Compose files target user signals, but init.sql /
  roles.sql created arq_monitor, so the collector could never
  authenticate). Renamed arq_signals / arq_monitor -> signals in
  examples/init.sql, examples/local-safe-role/signals.yaml.example,
  and examples/snapshot-example/snapshots.ndjson, and
  arq_monitor / arq_monitor_owner -> signals /
  signals_monitor_owner in the TimescaleDB demo
  (examples/timescaledb-demo/roles.sql, seed.sql) to match the
  names already wired in those demos' Compose files. Example-only
  change; no product behaviour is affected.

• Cleared remaining hyphenated arq-signals references from the
  examples (#143). Follow-up to #137/#127. Renamed the example SQLite
  store paths ./arq-signals.db / ./arq-signals-test.db ->
  ./signals.db / ./signals-test.db
  (examples/local-safe-role/signals.yaml.example,
  examples/local-superuser-override/signals.yaml.example) and the
  residual prose use of "arq-signals" as the product name ->
  "Elevarq Signals" in example comments and headers
  (examples/README.md, examples/docker-compose.yml,
  examples/docker-compose.prod.yml, examples/signals.yaml,
  examples/init.sql, examples/timescaledb-demo/docker-compose.yml).
  Service identifiers were already named signals; this is prose and
  example-path only, with no product behaviour impact.

• Cleared residual arq names from the deploy/ IaC templates
  (#145). #137 renamed ...

v0.10.0-beta.6

Added

• Secret-store credential provider (auth_method: secret_store, #93,
  #97). Fetch a static database password from a cloud secret store using
  the collector's ambient cloud identity and apply it as the connection
  password - keeping the credential out of Signals' config and off disk
  while leaving rotation to the vault. The backend is inferred from the
  shape of secret_ref: an AWS Secrets Manager ARN, an Azure Key Vault
  secret URI, or a GCP Secret Manager resource name; a reference matching
  none is a hard startup error naming the three accepted forms. The AWS
  Secrets Manager path is production-grade (region taken authoritatively
  from the ARN, never AWS_REGION / the SDK default chain / IMDS). Azure
  Key Vault and GCP Secret Manager are now production-wired as well (#108):
  each secret_ref is routed to exactly its inferred backend's SDK - Azure
  via the DefaultAzureCredential chain + azsecrets.GetSecret, GCP via
  Application Default Credentials + AccessSecretVersion - and no other
  backend's SDK is ever invoked (INV005). A backend the collector's ambient
  identity cannot reach is a connect-time, target-scoped failure that does
  not stop collection for other targets.
  An optional secret_json_key extracts a named key from a JSON secret
  (raw value otherwise); extraction failures never echo the raw secret. The
  fetched secret is cached per target with a reuse bound of min(vault TTL, max_cache_ttl) - with neither set it is re-fetched on every reconnect so
  a rotated secret is picked up without a restart. Validation enforces the
  passwordless and verify-full TLS floors at startup; the secret is never
  stored, exported, or logged (metadata only). Reuses the shared
  credential-provider scaffolding from #94. Live behaviour covered by an
  env-gated smoke (ARQ_SIGNALS_INTEGRATION_LIVE=1).
• GCP Cloud SQL IAM credential provider (auth_method: gcp_cloudsql_iam, #93, #96). Connect passwordlessly to Cloud SQL for
  PostgreSQL using Cloud SQL IAM database authentication: a short-lived
  Google OAuth2 access token acquired from the collector's ambient Google
  identity (Application Default Credentials - environment / GKE workload
  identity / service-account key / gcloud auth application-default login). The token (scope fixed at
  https://www.googleapis.com/auth/sqlservice.login) is the connection
  password over a direct libpq verify-full channel - the token-as-
  password seam, not the Cloud SQL Go Connector; no secret is stored in
  Signals' config. Tokens are cached per target and re-acquired ~5 minutes
  before their ~60 minute expiry, never shared across targets, and never
  logged or exported (metadata only). Validation enforces the passwordless
  and verify-full TLS floors at startup; an optional
  gcp_impersonate_service_account lets the ambient identity impersonate a
  per-target service account, and an undiscoverable identity or denied
  impersonation is a connect-time, target-scoped failure that does not stop
  collection for other targets. The Google SDK is linked only on the
  gcp_cloudsql_iam path - password targets require no Google credentials.
  Reuses the shared credential-provider scaffolding from #94. Live
  behaviour covered by an env-gated smoke
  (ARQ_SIGNALS_INTEGRATION_LIVE=1).
• Azure Entra ID credential provider (auth_method: azure_entra, #93,
  #95). Connect passwordlessly to Azure Database for PostgreSQL -
  Flexible Server using a short-lived Microsoft Entra ID access token
  acquired from the collector's ambient Azure identity (the
  DefaultAzureCredential chain: environment / AKS workload identity /
  managed identity / Azure CLI). The token (scope fixed at
  https://ossrdbms-aad.database.windows.net/.default) is the connection
  password; no secret is stored in Signals' config. Tokens are cached per
  target and re-acquired ~5 minutes before their ~60-90 minute expiry,
  never shared across targets, and never logged or exported (metadata
  only). Validation enforces the passwordless and verify-full TLS
  floors at startup; a user-assigned managed identity is disambiguated by
  the optional azure_client_id (then AZURE_CLIENT_ID), and an
  undiscoverable or ambiguous identity is a connect-time, target-scoped
  failure that does not stop collection for other targets. The Azure SDK
  is linked only on the azure_entra path - password targets require no
  Azure credentials. Reuses the shared credential-provider scaffolding
  from #94. Live behaviour covered by an env-gated smoke
  (ARQ_SIGNALS_INTEGRATION_LIVE=1).
• AWS RDS/Aurora IAM credential provider (auth_method: aws_rds_iam,
  #93, #94). Connect passwordlessly to Amazon RDS / Aurora PostgreSQL
  using a short-lived RDS IAM auth token minted from the collector's
  ambient AWS identity (SDK default credential chain: env / shared
  config / EC2 instance profile / ECS task role / EKS IRSA / Pod
  Identity). The token is the connection password; no secret is stored
  in Signals' config. Tokens are cached per target and re-minted ~3
  minutes before their 15-minute expiry, never shared across targets,
  and never logged or exported (metadata only). Validation enforces the
  passwordless and verify-full TLS floors at startup; a missing region
  is a startup warning resolved from AWS_REGION /
  AWS_DEFAULT_REGION / instance metadata (IMDS) at connect time. The
  AWS SDK is linked only on the aws_rds_iam path - password targets
  require no AWS credentials. Introduces the shared credential-provider
  scaffolding (auth_method dispatch, per-target token cache,
  BeforeConnect wiring) that sibling providers reuse. Live behaviour
  covered by an env-gated smoke (ARQ_SIGNALS_INTEGRATION_LIVE=1).

Changed

• Public binaries renamed to signals (daemon) and signalsctl
  (CLI) (#125). The open-source collector now ships under its own
  unbranded names so it can stand on its own, independent of the
  commercial Elevarq products. The container image moves to
  ghcr.io/elevarq/signals (Docker Hub mirror elevarq/signals), the
  Helm chart is renamed to signals, and the demo/quickstart surface
  (Dockerfiles, compose files, Helm install commands, Prometheus/Grafana
  examples, cloud deploy templates, and user-facing help text) now uses
  the new names throughout. The old names arq-signals and arqctl are
  retained as deprecation aliases: invoking either prints a one-line
  stderr warning and otherwise behaves identically. The aliases are
  removed one release after launch (tracked in #62). The Go module path
  (github.com/elevarq/arq-signals), the GitHub repository URL, the
  ARQ_SIGNALS_* environment variables, and the PostgreSQL
  application_name = 'arq-signals' collector identity are intentionally
  unchanged in this phase (config and integration interfaces, not binary
  branding).
• Release signature verification is forward-compatible with the repo
  rename (#131). The cosign verify --certificate-identity-regexp in
  the README, SECURITY.md, the release notes, and the release workflow
  now matches both the current Elevarq/Arq-Signals and the future
  Elevarq/signals workflow identity, so signature verification keeps
  working across the planned GitHub repository rename (#62) without a
  flag-day change.

---

Supply chain

• Images (same manifest digest in both registries):
  • GHCR: ghcr.io/elevarq/signals:0.10.0-beta.6
  • Docker Hub: elevarq/signals:0.10.0-beta.6 (when configured)
• Digest: sha256:ced51c346669960f90a4cc0d5b0564cd2e8aafa00f51629cad9883f9d228aa4b
• Architectures: linux/amd64, linux/arm64
• Cosign-signed in both registries (keyless, GitHub OIDC)
• SBOM attached as OCI attestation and as sbom.spdx.json release asset
• SLSA build provenance attestation (mode=max)

Quick signature verification (GHCR):

cosign verify ghcr.io/elevarq/signals:0.10.0-beta.6   --certificate-identity-regexp='github.com/Elevarq/(Arq-Signals|signals)/.github/workflows/release.yml@'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Same command works against elevarq/signals:0.10.0-beta.6 — the certificate identity is bound to the workflow, not the registry.

Full verification checklist (manifest, SBOM, provenance, Trivy):
docs/release-verification.md

v0.10.0-beta.5

Re-cut of v0.10.0-beta.4: that tag's publish job died at the Docker
Hub login (expired mirror token) before the GHCR image, chart, and
GitHub Release published (#82). Same data-collection layer as
beta.4 - only the release pipeline changed (Docker Hub login is now
non-fatal; GHCR-only on mirror-credential failure). beta.4 preserved
below for history.

---

Supply chain

• Images (same manifest digest in both registries):
  • GHCR: ghcr.io/elevarq/arq-signals:0.10.0-beta.5
  • Docker Hub: elevarq/arq-signals:0.10.0-beta.5 (when configured)
• Digest: sha256:460c0c8eb3acc751c4651cb3310fee588efe5699a268da8de2d636b36eb5800a
• Architectures: linux/amd64, linux/arm64
• Cosign-signed in both registries (keyless, GitHub OIDC)
• SBOM attached as OCI attestation and as sbom.spdx.json release asset
• SLSA build provenance attestation (mode=max)

Quick signature verification (GHCR):

cosign verify ghcr.io/elevarq/arq-signals:0.10.0-beta.5   --certificate-identity-regexp='github.com/Elevarq/Arq-Signals/.github/workflows/release.yml@'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Same command works against elevarq/arq-signals:0.10.0-beta.5 — the certificate identity is bound to the workflow, not the registry.

Full verification checklist (manifest, SBOM, provenance, Trivy):
docs/release-verification.md

v0.10.0-beta.3

Re-cut after release-pipeline fix. v0.10.0-beta.2's container
image and GitHub Release were published successfully, but the
publish-chart job failed to sign the Helm chart with cosign — the
job authenticated GHCR via helm registry login (helm's own config),
not the docker keychain cosign reads. The fix
(docker/login-action before Sign chart) is now on main. Same
data-collection layer as beta.2; this artifact's chart is signed.
Also fixes the prerelease flag on the GitHub Release page that beta.2
was missing (action-gh-release@v3 no longer auto-detects from the
semver suffix). (#50)

---

Supply chain

• Images (same manifest digest in both registries):
  • GHCR: ghcr.io/elevarq/arq-signals:0.10.0-beta.3
  • Docker Hub: elevarq/arq-signals:0.10.0-beta.3 (when configured)
• Digest: sha256:17440ab583728621203d9aa191e188d5868b0232aa7d8b63329d4a8fffc47f31
• Architectures: linux/amd64, linux/arm64
• Cosign-signed in both registries (keyless, GitHub OIDC)
• SBOM attached as OCI attestation and as sbom.spdx.json release asset
• SLSA build provenance attestation (mode=max)

Quick signature verification (GHCR):

cosign verify ghcr.io/elevarq/arq-signals:0.10.0-beta.3   --certificate-identity-regexp='github.com/Elevarq/Arq-Signals/.github/workflows/release.yml@'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Same command works against elevarq/arq-signals:0.10.0-beta.3 — the certificate identity is bound to the workflow, not the registry.

Full verification checklist (manifest, SBOM, provenance, Trivy):
docs/release-verification.md

v0.10.0-beta.2

Beta cut after Scorecard hardening. v0.10.0-beta.1 was tagged but
its release pipeline run was cancelled (stuck on multi-arch GHCR
publish); the GitHub Release page was never created. This Beta cut is
the same data-collection layer (no user-observable daemon behaviour
change vs beta.1) but built and published from a main whose CI /
supply-chain posture has been hardened — see Security below. Consumers
should pin 0.10.0-beta.2; :latest is unmoved (pre-release).

Security

• All GitHub Actions and Docker base images in
  ci.yml / release.yml / nightly-security.yml / Dockerfile are
  pinned by 40-char content SHAs (#44). Defends against tag-rewriting
  / repo-takeover supply-chain attacks; Dependabot
  (.github/dependabot.yml, #34) keeps both the SHA and the
  human-readable version comment fresh.
• release.yml top-level workflow permissions reduced to
  contents: read. Writes (packages: write, id-token: write,
  attestations: write, contents: write on the release job) are
  declared per-job following the nightly-security.yml pattern (#39).
• golang.org/x/sys bumped past CVE-2026-39824 (#30). The
  vulnerable windows.NewNTUnicodeString is not reachable in our
  linux / darwin builds, but the bump clears the indirect-vuln
  trail.
• go install golang.org/x/vuln/cmd/govulncheck pinned by SHA to the
  v1.3.0 commit (#47).
• Native Go fuzz targets added for RedactDSN and DecodeNDJSON
  (#43). >450k iterations across both targets find no panics or
  property violations at this commit.
• Branch protection applied to main: required status checks
  (test, security-scan, Analyze (go), Analyze (actions),
  CodeQL), strict (require branch up-to-date), linear history,
  no force pushes, no deletions.

Changed (deps)

• Dependabot routine bumps: hadolint/hadolint-action ->
  3.3.0 (#35), azure/setup-helm -> v5 (#36),
  actions/download-artifact -> v8 (#37),
  softprops/action-gh-release -> v3 (#38),
  actions/upload-artifact -> v7 (#40), and a gomod minor-group
  bundle across four modules (#41).

---

Supply chain

• Images (same manifest digest in both registries):
  • GHCR: ghcr.io/elevarq/arq-signals:0.10.0-beta.2
  • Docker Hub: elevarq/arq-signals:0.10.0-beta.2 (when configured)
• Digest: sha256:bb11230013117939d0e859105dee99b0051f8c21879ee90ef39d8922cdc75c96
• Architectures: linux/amd64, linux/arm64
• Cosign-signed in both registries (keyless, GitHub OIDC)
• SBOM attached as OCI attestation and as sbom.spdx.json release asset
• SLSA build provenance attestation (mode=max)

Quick signature verification (GHCR):

cosign verify ghcr.io/elevarq/arq-signals:0.10.0-beta.2   --certificate-identity-regexp='github.com/Elevarq/Arq-Signals/.github/workflows/release.yml@'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Same command works against elevarq/arq-signals:0.10.0-beta.2 — the certificate identity is bound to the workflow, not the registry.

Full verification checklist (manifest, SBOM, provenance, Trivy):
docs/release-verification.md

v0.9.0

Added

• Broader read-only catalog coverage: additional collectors capture
  user-defined catalog objects and extended statistics so dependent
  tables and queries are fully represented in a snapshot for downstream
  analysis.
• Optional per-collector view in the export ZIP.
• Extra PG 14+ session counters in pg_stat_database; role oid in
  login_roles for stable role-name resolution; pg_settings context
  and value bounds.

Still read-only by design — three-layer enforcement, no write
operations, no telemetry, no AI.

---

Supply chain

• Images (same manifest digest in both registries):
  • GHCR: ghcr.io/elevarq/arq-signals:0.9.0
  • Docker Hub: elevarq/arq-signals:0.9.0 (when configured)
• Digest: sha256:270c543d426b3dff71e85db2665a8a9e5b669f959c76ec51fdef4ddd863ed187
• Architectures: linux/amd64, linux/arm64
• Cosign-signed in both registries (keyless, GitHub OIDC)
• SBOM attached as OCI attestation and as sbom.spdx.json release asset
• SLSA build provenance attestation (mode=max)

Quick signature verification (GHCR):

cosign verify ghcr.io/elevarq/arq-signals:0.9.0   --certificate-identity-regexp='github.com/Elevarq/Arq-Signals/.github/workflows/release.yml@'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Same command works against elevarq/arq-signals:0.9.0 — the certificate identity is bound to the workflow, not the registry.

Full verification checklist (manifest, SBOM, provenance, Trivy):
docs/release-verification.md