Caddy Version bump to 2.11.1

[Wikid82]

Charon’s control plane and data plane rely on Caddy as a core runtime backbone.
Because Caddy is embedded and rebuilt via xcaddy, upgrading from
2.11.0-beta.2 to 2.11.1 is not a routine version bump: it impacts
runtime behavior, plugin compatibility, vulnerability posture, and potential UX
surface area.

This plan defines a low-risk, high-observability rollout strategy that answers:

Which Caddy 2.11.x features should be exposed in Charon UI/API?
Which existing Charon workarounds became redundant upstream?
Which xcaddy dependency patches remain necessary vs removable?
Which known vulnerabilities are fixed now and which should remain on watch?

[codecov]

Codecov Report

❌ Patch coverage is 83.18584% with 19 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
backend/internal/api/handlers/settings_handler.go	75.67%	5 Missing and 4 partials ⚠️
backend/internal/caddy/manager.go	72.41%	4 Missing and 4 partials ⚠️
frontend/src/pages/SystemSettings.tsx	92.30%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

Updates the active plan document to outline a phased, evidence-driven rollout strategy for upgrading embedded Caddy (via xcaddy) to v2.11.1, focusing on compatibility, security advisories, and potential UX/API exposure.

Changes:

• Replaces the prior “hostname validation test failures” plan with a comprehensive Caddy 2.11.1 compatibility/security/UX impact plan.
• Adds plugin compatibility risk analysis, security advisory tracking rubric, and xcaddy patch retirement gates.
• Introduces a phased implementation plan and PR slicing strategy (PR-1/PR-2/PR-3) with explicit validation/rollback criteria.

Comments suppressed due to low confidence (3)

docs/plans/current_spec.md:208

• These markdown tables use a double leading pipe ||, which typically renders as an extra empty column (or otherwise degrades table rendering depending on the renderer). Update to standard markdown table syntax with single leading pipes so the rubric stays readable in GitHub and other viewers.

| Field | Required Values | Rule |
| --- | --- | --- |
| Exploitability | `Affected` / `Not affected` / `Mitigated` | `Affected` means a reachable vulnerable path exists in Charon runtime; `Not affected` means required feature/path is not present; `Mitigated` means vulnerable path exists upstream but Charon deployment/runtime controls prevent exploitation. |
| Evidence source | advisory + code/config/runtime proof | Must include at least one authoritative upstream source (GitHub advisory/Caddy release) and one Charon-local proof (config path, test, scan, or runtime verification). |
| Owner | named role | Security owner for final disposition (`QA_Security` lead or delegated maintainer). |
| Recheck cadence | `weekly` / `release-candidate` / `on-upstream-change` | Minimum cadence: weekly until CVE enrichment is complete and disposition is stable for two consecutive checks. |

docs/plans/current_spec.md:275

• Same table-formatting issue here (|| at line start). Converting to standard markdown table syntax will prevent an extra blank column and keep the decision matrix easy to scan.

| Feature | Control surface | Expose vs backend-only rationale | Persistence path |
| --- | --- | --- | --- |
| `keepalive_idle`, `keepalive_count` | Existing advanced system settings (if approved) | Expose only if operators need deterministic upstream connection control; otherwise keep backend defaults to avoid UX bloat. | `frontend/src/pages/SystemSettings.tsx` → `frontend/src/api/settings.ts` → `backend/internal/api/handlers/settings_handler.go` → DB settings → `backend/internal/caddy/config.go` (`GenerateConfig`) |
| `trusted_proxies_unix` | Backend-only default initially | Backend-only until proven demand for unix-socket trust tuning; avoid misconfiguration risk in general UI. | backend config model (`backend/internal/caddy/types.go`) + generated config path (`backend/internal/caddy/config.go`) |
| `renewal_window_ratio`, cert maintenance interval | Backend-only policy | Keep backend-only unless operations requires explicit lifecycle tuning controls. | settings store (if introduced) → `settings_handler.go` → `GenerateConfig` |
| Reverse-proxy Host rewrite / ECH rotation / reload fallback internals | Backend-only | Operational internals with low direct UI value; exposing would increase complexity without clear user benefit. | backend runtime defaults and generated Caddy config only |

docs/plans/current_spec.md:192

• “timberjack” appears to be a typo; the common name for the Go log-rotation library is “lumberjack” (and readers may search for that term).

4. Logging backend internals (`timberjack`, ordering fixes)

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[github-actions]

✅ Supply Chain Verification Results

✅ PASSED

📦 SBOM Summary

• Components: 1670

🔍 Vulnerability Scan

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	10
🟢 Low	4
Total	14

📎 Artifacts

• SBOM (CycloneDX JSON) and Grype results available in workflow artifacts

---

_{Generated by Supply Chain Verification workflow • View Details}