Skip to content

Release readiness: resolve audit blockers and qualify the September 17 candidate #638

Description

@defangdevs

Release target: 2026-09-17. Audit baseline: 0cc18b8, still current master when the findings were filed on 2026-09-10.

No P0 was confirmed by this audit. The P1 findings below are release blockers for the affected supported capabilities. They require local access, operator interaction, a particular deployment configuration, or correction of the release process; no unauthenticated Internet takeover of the default deployment was demonstrated. This triage is not a claim that an exhaustive security assessment found no other vulnerabilities.

V1 fixes and remaining release blockers (P1)

Conditional security and reliability follow-up (P2)

Post-v1 scope and simplification

These are existing or separately filed issues, not additional implementations to duplicate inside this tracker. Historical incident narratives can move to the wiki while preserving short invariants beside the code.

Scope and evidence required before promotion

Confirmed scope: single-user VMs for v1 (one Linux agent user per box), with no shared tenancy. Multi-user support is post-v1. Browser-origin security, credential handling, and single-user reliability remain in scope. The supported backend/cloud/architecture matrix and portal inclusion still need an explicit release decision; native Ubuntu and one fresh-boot-qualified cloud path remain the proposed minimum. Do not claim shared-tenancy isolation for v1.

  • Confirm the tenancy scope: single-user VMs; multi-user support is post-v1.
  • Freeze new features and record the supported backend/cloud/architecture matrix and portal inclusion.
  • Add SECURITY.md with a private reporting route, supported versions, and credential recovery guidance; verify private vulnerability reporting is enabled/configured.
  • Preserve existing secret scanning and push protection; record a dependency/secret scan and resolve release-impacting results.
  • Keep a checked inventory of declared native/VM checks and CI membership, including coverage of source/test changes in workflow triggers.
  • Enumerate and run all current native checks and required x86 VM scenarios against the actual candidate. Keep browser-origin and single-user regressions in scope; two-user qualification is deferred with shared tenancy.
  • Fresh-deploy the chosen cloud artifact and exercise sign-in, sessions, reconnect, downloads, and password rotation. Renderer fixtures alone do not qualify a cloud bootstrap.
  • Exercise reboot, interrupted/failed update, rollback, restore, and an overnight soak with preserved session data.
  • Record immutable source/dependency/template identities, and promote exactly the tested artifacts. Do not publish a separately resolved unstable dependency set.

Baseline audit evidence (2026-09-10): all 34 then-declared aarch64 native checks passed. The webhook size guard failed at 130805 bytes and was omitted from CI at that baseline; #645 subsequently reduced the script and wired the guard into CI. These baseline results do not qualify a later release candidate.

PR review evidence (2026-09-11): reviewed #650, #653, #654, #655, #656, #659 and #648, including cumulative master 88a290b for merged fixes. No reviewed merged issue needed reopening. Locally, 41 download + 42 registry + 16 session-route + 21 release-manifest + 20 changed-path tests passed (140 total). A disposable ttyd probe accepted the matching origin and closed the foreign-origin request without upgrading. Manifest probes reproduced the rollback pin drift and older-candidate checkout mismatch. Existing PR CI was green; no new cloud deployments or local x86 VM/browser suites were run. No production configuration was changed.

#634, #635, #636 and #637 remain open; no associated fix PR was found during this review. Do not mark them complete based on the other audit PRs. The detailed review update records the scope and findings.

Work order for the week

  1. Freeze scope and enforce CI/review/promotion requirements.
  2. Preserve the single-user publishing workflow; defer shared-tenancy redesign.
  3. Fix download and chosen-cloud credential handling.
  4. Verify the merged lock-refusal and test-guard fixes on the candidate; finish remaining in-scope reliability work.
  5. Fresh-deploy the chosen candidate and complete dependency/secret checks.
  6. Prove recovery/rollback, then soak.
  7. Record go/no-go and promote only if all supported-scope gates pass.

If the work does not fit the available staffing, reduce the supported feature set or delay the affected capability rather than weakening the security gates. Broad framework/backend rewrites are outside this release week.

Repository ownership

All confirmed defects here are owned by agent-box. In particular, JWKS and HTTP parsing live in modules/src/settings-daemon.py; ttyd/Caddy behavior is controlled by agent-box's integration; the registry and installation loop are agent-box code. No new local-channels defect was established by this audit, so no duplicate/speculative upstream issue was filed there. Webhook HMAC authenticates a sender service, not the trustworthiness of an issue author's content; credentials and autonomous-dispatch authority must remain scoped accordingly.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1Fix next: silent data loss or capability already degradedtaskGeneral task / chore

Projects

  • Status
    Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions