Document user-directed retention of recording signing key

Preserve the unresolved release finding without inventing an exception or changing recording trust.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Cédric Verstraeten
2026-11-05 10:28:08 +01:00
co-authored by Copilot App
parent 29537da6e8
commit 7b95de7c10
2 changed files with 10 additions and 4 deletions
+3
View File
@@ -168,6 +168,9 @@ policy exception**, so this is not a claim of full image-hardening baseline or
CIS compliance.
Release promotion is also blocked by remaining native-library scan findings
and the legacy default recording-signing key; this PR is not release-qualified.
The existing signing key and recording-trust behavior are retained by explicit
user decision. This does not waive the key's security finding or approve a
release exception.
If you want to connect to a USB or Raspberry Pi camera, [you'll need to run our side car container](https://github.com/kerberos-io/camera-to-rtsp) which proxies the camera to an RTSP stream. In that case you'll want to configure the Kerberos Agent container to run in the host network, so it can connect directly to the RTSP sidecar.
+7 -4
View File
@@ -171,7 +171,8 @@ their application inventory/SBOM, because compiled browser assets hide lockfile
metadata from final-rootfs scanners. Final-image evidence separately covers native
packages and the Go binary. Current native-library findings and the legacy
embedded default recording-signing private key are still release blockers; the
key's trust/migration behavior has not been silently changed or waived.
existing key and recording-trust behavior are retained by explicit user decision.
That decision is not a scanner suppression or an approved release exception.
The build jobs run compilation and production-image smoke tests before the
security gates. A job that fails at **Source/UI dependency and final image gates
@@ -191,9 +192,11 @@ had no vendor-scanner findings but still used the same affected upstream
adopted to obtain a misleading clean scan. A newer media stack needs matched
CGO headers/libraries and validation of codecs, hardware acceleration and
supported architectures, not an unreviewed mix of testing-distribution packages.
The default recording-signing key also needs an explicit trust migration:
per-installation keys need verifier/public-key provisioning, while requiring
an injected key changes startup for existing keyless installations.
The user has chosen to keep the default recording-signing key; no trust
migration or startup change is implemented. Its source-secret finding remains
an unresolved release blocker. Any future removal would require a separately
authorized migration: per-installation keys need verifier/public-key provisioning,
while requiring an injected key changes startup for existing keyless installations.
Before deploying, obtain the release's digest, source revision, supported
platforms, per-platform SBOM/scan reports, provenance, signature certificate