1 Commits

Author	SHA1	Message	Date
shankar0123	57d55b7390	refactor(config): extract EST family + helpers to its own file (Phase 9, 4 of N) ... Continuing Phase 9 ARCH-M2 closure. Sprint 4 extracts the EST surface, mirroring Sprint 3's SCEP cut shape (two structs + multiple helpers move together). What moved ========== internal/config/est.go (new, 396 lines including BSL header + Phase 9 doc-comment + 2 imports + 2 structs + 5 helpers) Two structs: - ESTConfig (top-level: Enabled + Profiles slice + legacy single-issuer flat fields kept for backward compat — fewer trigger fields than SCEP because EST has no per-profile RA pair or challenge password in this hardening-bundle phase) - ESTProfileConfig (one EST endpoint: PathID, IssuerID, ProfileID, EnrollmentPassword, MTLSEnabled, MTLSClientCATrustBundlePath, ChannelBindingRequired, AllowedAuthModes, RateLimitPerPrincipal24h, ServerKeygenEnabled — field surface spans the full Phase-1-through-5 hardening bundle) Five unexported helpers: - loadESTProfilesFromEnv() — reads CERTCTL_EST_PROFILES + expands each name into an ESTProfileConfig via the indexed env-var family. Mirrors loadSCEPProfilesFromEnv exactly. - parseAuthModes() — splits a comma-separated env value into a normalized []string of auth-mode tokens. - mergeESTLegacyIntoProfiles() — backward-compat shim: synthesize Profiles[0] from the legacy flat fields when Profiles is empty AND EST is enabled. - validESTPathID() — path-segment validator (mirrors validSCEPPathID; kept separate so future EST-specific path constraints can land without affecting SCEP). - validESTAuthMode() — refuses unknown auth-mode tokens at startup ("mtls" / "basic" are valid in Phase 1). Why move all five helpers together ================================== Live grep confirms each helper is exclusively EST-specific: - parseAuthModes() has one production call site (line 1851 inside loadESTProfilesFromEnv itself, intra-helper) + one test caller (config_est_profiles_test.go in package `config` — same package so the move is invisible to the test). - validESTAuthMode() has exactly one production caller (Validate() in config.go); validESTPathID() likewise. - mergeESTLegacyIntoProfiles() called from Load() in config.go. - loadESTProfilesFromEnv() called from Load() in config.go. All callers either stay in config.go (Load + Validate) or live in est.go itself (the intra-helper parseAuthModes call inside loadESTProfilesFromEnv stays a same-file call after the move — one LESS cross-file edge to track). The test in config_est_profiles_test.go is in package `config` so the unexported callable surface is preserved by same-package resolution. What stayed in config.go (intentionally) ======================================== - Load() and Validate() bodies — the EST-specific call sites stay where they are (cross-cutting validation logic, not split-target). - Every shared getEnv* helper (used by EVERY config family). - The Config{}.EST master-struct field declaration. Edit shape ========== Two sed passes (same approach as Sprint 3): 1. sed -i '611,774d' — deleted the 164-line EST struct block (ESTConfig + ESTProfileConfig + their doc comments). 2. sed -i '1648,1789d' — deleted the 142-line helper block (positions already shifted by Sprint 4's struct removal). Then gofmt -w to collapse a residual double-blank-line at the second join point (none surfaced at the first). Public-surface invariant ======================== Every type, field, exported method, and doc-comment is byte-identical to pre-split. Package stays `config`. Every caller's `config.ESTConfig` / `config.ESTProfileConfig` import path is preserved without modification. The five helpers are unexported so their move is invisible to package consumers; same-package callers (Load, Validate, the existing test) continue to resolve them via the package symbol table. Verification (all clean): gofmt -l internal/config/ → clean (after -w) go build ./internal/config/... → clean go test ./internal/config/... -count=1 → ok (0.58s) staticcheck ./internal/config/... → clean go build ./internal/api/router/... ./internal/scheduler/... ./cmd/server/... ./internal/api/handler/... → clean (broader importers still resolve every type and helper) grep -nE '^type EST|^func .*EST|^func parseAuthModes' config.go → empty (none remain in config.go) grep -nE '^type EST|^func .*EST|^func parseAuthModes' est.go → 2 types + 5 funcs (correct: ESTConfig, ESTProfileConfig, loadESTProfilesFromEnv, parseAuthModes, mergeESTLegacyIntoProfiles, validESTPathID, validESTAuthMode) LOC delta: config.go: 2774 → 2467 (-307 lines: -164 from struct block, -142 from helper block, -1 from double-blank collapse) est.go: new, 396 lines (incl. 87-line Phase 9 doc-comment + BSL header + package decl + 2 imports) Cumulative Phase 9 progress (Sprints 1+2+3+4 from config.go): Pre-Phase-9: 3403 LOC After Sprint 1 (Notifier): 3335 LOC (-68) After Sprint 2 (ACME): 3108 LOC (-227) After Sprint 3 (SCEP): 2774 LOC (-334) After Sprint 4 (EST): 2467 LOC (-307) Total Sprint 1+2+3+4: -936 LOC (-27.5%) Pattern lesson reinforcement ============================ Sprint 4 confirms the SCEP/EST symmetry the original helper authors documented inline ("Mirrors loadSCEPProfilesFromEnv exactly"). Sprint 3 + Sprint 4 are now demonstrating the same cut pattern works across two related-but-distinct protocol surfaces. Sprint 5+ should be easier because they don't carry the same helper-bundling complexity (Auth family probably has its own helper cluster too, but Server / Issuers are likely pure-data per the original audit-questions output). Next queued (Sprint 5): Auth family from config.go → internal/config/auth.go. Includes AuthConfig + SessionConfig + BreakglassConfig + NamedAPIKey + ParseNamedAPIKeys (note: this is EXPORTED — only exported function in the config-helpers cluster) + isValidKeyName + ValidAuthTypes. The exported ParseNamedAPIKeys adds a wrinkle Sprints 1-4 didn't have: external callers may import it, so the public-surface check needs to include it. Estimated ~340 LOC moved. Closes: cowork/certctl-architecture-diligence-audit.html#fix-ARCH-M2 (partial — 4 of 12 — full ARCH-M2 closure is the aggregate)	2026-05-14 04:26:57 +00:00