a9ad0eb841
Comprehensive design spec for a confined, env-scoped alerting feature: 6 signal sources, shared env-scoped rules with RBAC-targeted notifications, in-app inbox + webhook delivery via admin-managed outbound connections, claim-based polling for horizontal scalability, 4 CH projections for hot-path reads. Backlog entry BL-001 / gitea#137 tracks deferred managed-CA investigation (reuse SaaS-layer CA handling first before building in-server storage). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.3 KiB
Backlog
Deferred items surfaced during design / planning / execution that we've decided not to build right now but want to keep visible. Append-only — close items by marking them and moving to the "Closed" section with a link to the delivering commit/spec.
Open
BL-001 — Managed CA bundles for outbound HTTPS
Opened: 2026-04-19 Surfaced by: Alerting design — TLS trust section Tracking: gitea#137 Status: Open
Context. The alerting feature introduces server → external HTTPS webhooks, which makes outbound TLS trust a cross-cutting concern (joining the existing OIDC token-exchange / JWKS fetch paths). Alerting v1 handles this with a shared OutboundHttpClientFactory + system config (cameleer.server.outbound-http.trusted-ca-pem-paths) + a per-webhook TrustMode override (SYSTEM_DEFAULT / TRUST_ALL / TRUST_PATHS). CA files in v1 are filesystem-resident, managed via deployment config — there is no in-app upload surface.
What's deferred.
-
In-app CA bundle management. Admin UI to upload, list, and delete trusted CA PEMs. Storage in PG (
trusted_ca_certstable) so all replicas see a consistent set without a filesystem sync step. Likely lives under/admin/outbound-http(new admin surface) or as a tab on the existing admin navigation. -
SaaS-layer CA reuse — design investigation (do first). The SaaS layer already manages CA material for the server (for its reverse-proxy → OIDC path and related). Before building in-app CA management in the OSS server, investigate whether the SaaS CA mechanism can be extended/exposed so the server can consume trust material from the SaaS layer directly. Goal: KISS + DRY — don't duplicate a CA store in the server if the SaaS side already owns one. If reuse is viable, in-app CA upload in the server may never be needed — the SaaS layer becomes the authoritative admin surface and the server just reads.
Acceptance criteria.
- Investigation concludes with a one-page decision: reuse SaaS / build in-server / hybrid, with rationale and an implementation sketch.
- If "build in-server" is chosen: spec + plan + implementation following the normal flow. Must include PG-backed storage, audit logging on CA change (category already introduced:
OUTBOUND_HTTP_TRUST_CHANGE), and cluster-consistent propagation. - If "reuse SaaS" is chosen: spec for the extension on the SaaS side + a small server-side consumer; the server's current file-path-based trust config remains as the OSS fallback for non-SaaS deployments.
Why we're not doing it now.
- Alerting v1's file-based trust config is identical to how the server handles other trust material today (OIDC issuer URIs, Ed25519 keys), so it's no regression.
- Building in-server CA management before the SaaS reuse investigation risks duplicating work we may throw away.
- Most early alerting users will target public SaaS webhooks (Slack, PagerDuty, Teams) whose certs chain to public roots — no custom CA needed.
Links.
cameleer-server-app/src/main/java/com/cameleer/server/app/http/(v1 outbound HTTP module — the investigation will extend this)- OIDC trust touch-points in
OidcProviderHelper,OidcTokenExchanger(alignment reference)
Closed
(nothing yet)