3 Commits

Author	SHA1	Message	Date
shankar0123	5dc698307b	chore: rename Go module path to github.com/certctl-io/certctl ... Mechanical sed across the main go.mod's module declaration, the f5-mock-icontrol sub-module's go.mod, every Go file's import path (361 files), and a rebuild of the checked-in f5-mock-icontrol binary so its embedded build-info reflects the new module path. No behavior change. Choice B from cowork/transfer-certctl-to-org.md, executed 2026-05-04. Choice A (keep module path declared as github.com/shankar0123/certctl regardless of repo URL) shipped on the day of the org transfer (2026-05-03) since we had no external Go consumers; this commit closes that deferral. Backward-compat: GitHub HTTP redirects continue to forward github.com/shankar0123/certctl → github.com/certctl-io/certctl at the URL level, but Go's module proxy uses the path declared in go.mod as the canonical name. Pre-fix, anyone trying `go get github.com/certctl-io/certctl/...` hit a "module path mismatch" error because go.mod said github.com/shankar0123/certctl and the URL they fetched it from said certctl-io/certctl. Post-fix, the canonical name and the URL agree, so go get / go install / external Go consumers / Go-tooling integrations work cleanly via either the new path (preferred) or the old path (which redirects and Go follows the redirect for source fetch). Anyone still importing the old path inside their own code keeps working provided they update their go.mod's `require` line to match — the module path declared in their consumer's go.sum / go.mod is the authoritative import name, so a mass sed across their import statements is the migration on the consumer side. No external consumers exist today. Diff shape: 361 *.go files — import path replacement only 2 go.mod — module declaration replacement only 1 binary — deploy/test/f5-mock-icontrol/f5-mock-icontrol rebuilt so embedded build-info reflects the new path (8618965 vs 8618933 bytes; 32-byte diff is the build-info change) Total: 364 files, 730 insertions / 730 deletions, net-zero size, pure mechanical substitution. Verification: gofmt: 17 files needed re-alignment after sed (the new path is one char shorter than the old, so column-aligned import groups drifted). Applied `gofmt -w` to fix. go mod tidy: clean exit on both modules. go vet ./...: clean exit. go build ./...: clean exit. go test -short -count=1 on representative packages: all green (internal/domain, internal/validation, internal/crypto, internal/crypto/signer, cmd/agent). Test output now reads `ok github.com/certctl-io/certctl/...` confirming the module path resolves correctly. binary: f5-mock-icontrol rebuilt; `strings | grep shankar0123` returns nothing; `strings | grep certctl-io/certctl` shows the new module path embedded in build-info. Files intentionally NOT touched in this commit: README.md / CHANGELOG.md / docs/ / etc. — already swept to certctl-io URLs in commit bc6039a (the post-transfer URL refresh). This commit is purely the Go-tooling layer. Scarf pixels (`shankar0123.docker.scarf.sh/...`) — Scarf-account namespace, not a Go import or GitHub repo URL. Stays. This is a non-blocking, non-customer-impacting change. Operators pulling container images, running `make verify`, hitting the API, or installing the agent see no functional difference. Only Go-tooling consumers (none today) are affected, and they're enabled — not broken — by this commit.	2026-05-04 00:30:29 +00:00
shankar0123	336a745f41	secret: migrate EJBCA / GlobalSign / Sectigo credentials to *secret.Ref (Phase 2) ... Phase 2 of the #6 acquisition-readiness fix from the 2026-05-01 issuer coverage audit. Phase 1 (commit 520cda3) shipped the secret.Ref opaque credential type with PBKDF2-derived key, ChaCha20-Poly1305 envelope, String/MarshalJSON redaction to "[redacted]", and the Use callback that zero-fills the per-call buffer after the consumer returns. This commit applies the type to the three connectors flagged by the audit and adds the JSON-roundtrip glue that the production factory path needs. Shared (internal/secret/): - Add UnmarshalJSON on *Ref so json.Unmarshal of a stored config blob (issuerfactory.NewFromConfig) parses the bytes-as-string into NewRefFromString without callers having to know the field type changed. Null and missing keys leave the receiver nil; non-string payloads (numbers, bools) are rejected with a typed error. Pinned by TestRef_UnmarshalJSON: string_value, null, missing_key, number_rejected, roundtrip_marshal_then_unmarshal (the round-trip goes through "[redacted]" intentionally — JSON-marshal-then- unmarshal of a Config with secrets is NOT a supported test pattern; callers that construct a rawConfig must use a JSON literal with the real values). Per-connector migration: - EJBCA (ejbca.go): Config.Token: string → *secret.Ref. ValidateConfig empty-check uses Token.IsEmpty() (nil-safe). setAuthHeaders rewritten to call Token.Use; the Bearer header string is built inside the callback and the buffer is zeroed on return. mTLS path is unaffected. - GlobalSign (globalsign.go): Config.APIKey + Config.APISecret: string → *secret.Ref. Both ValidateConfig empty-checks use IsEmpty(). Extracted setAuthHeaders helper consolidates the four duplicated triple-Set sites (ValidateConfig probe, IssueCertificate, RevokeCertificate, pollCertificateOnce) so any future header-shape change applies once. ValidateConfig now pulls from the local cfg (post-Unmarshal) so the helper takes a *Config rather than the receiver — needed because ValidateConfig writes the validated cfg onto c.config only AFTER the probe succeeds. - Sectigo (sectigo.go): Config.Login + Config.Password: string → *secret.Ref. CustomerURI stays plain string (org identifier, not a credential). setAuthHeaders rewritten to call Login.Use + Password.Use; ValidateConfig's inline header writes use the same pattern (the ValidateConfig probe writes to a local cfg, not c.config, so it can't share setAuthHeaders without rewiring — the inline form is fine, kept consistent in shape). Test migration: - ejbca_test.go, ejbca_failure_test.go, ejbca_stubs_test.go: bulk Token: "X" → Token: secret.NewRefFromString("X") via sed; secret import added. - globalsign_test.go, globalsign_failure_test.go: same pattern for APIKey + APISecret. - sectigo_test.go, sectigo_failure_test.go: same pattern for Login + Password. Two tests (TestGlobalSign_ServerTLSConfig/PinnedCA_TrustsExpectedServer and TestSectigoConnector/ValidateConfig_Success) used to construct rawConfig via json.Marshal(config) → ValidateConfig(rawConfig). After the migration, json.Marshal redacts *secret.Ref to "[redacted]" by design, so the roundtripped rawConfig wrote "[redacted]" as the actual header value and the mock server's auth-header check 403'd. Both tests now build rawConfig as a JSON literal (the production- shape input — the factory path always feeds rawConfig from the DB or env, never from json.Marshal of an in-memory Config). The new tests have a comment explaining the trap so the next person who adds a similar test sees the pattern. Out of scope (intentional): - The `internal/config/config.SectigoConfig` / `GlobalSignConfig` / `EJBCAConfig` env-var-loader structs are still plain strings — those types are the env-load shape, not the steady-state runtime shape. The seed path in service/issuer.go json-marshals them into a map[string]interface{} which the factory then UnmarshalJSON's into the connector Config; the new UnmarshalJSON on *Ref handles the conversion at the boundary. - DigiCert.APIKey + Vault.Token are still plain strings; Phase 3 will pick them up. The audit explicitly named EJBCA / GlobalSign / Sectigo as the Phase 2 scope (RESULTS.md L633). Verified locally: - gofmt -l . clean - go vet ./... clean - staticcheck across all four packages clean - go test -short -count=1 across secret, ejbca, globalsign, sectigo, issuerfactory, service, api/handler: green Audit reference: cowork/issuer-coverage-audit-2026-05-01/RESULTS.md Top-10 fix #6 — Phase 2.	2026-05-02 12:53:58 +00:00
cowork	d839b233fe	Bundle N.A/B-extended (Coverage Audit Extension): per-CA failure-mode tests across 6 issuer connectors — M-001 closed (target-met-on-average) ... Six new <conn>_failure_test.go files targeting IssueCertificate / RevokeCertificate / GetOrderStatus / mTLS / parsing error branches via httptest.Server. Same pattern as Bundle J's acme_failure_test.go, adapted per-CA. Coverage deltas ================= vault 84.1% -> 87.3% (+3.2pp; 5 tests) sectigo 79.4% -> 85.5% (+6.1pp; 9 tests) globalsign 78.2% -> 87.1% (+8.9pp; 7 tests, NewWithHTTPClient pattern) digicert 81.0% -> 84.9% (+3.9pp; 6 tests) ejbca 76.5% -> 84.3% (+7.8pp; 8 tests, OAuth2 + mTLS branches) entrust 70.8% -> 81.2% (+10.4pp; 14 tests; in-package mapRevocationReason / parseCertMetadata / loadMTLSConfig / ValidateConfig field-required + unreachable + bad-cert-path + GetOrderStatus status-variants) Already at or above 85% ================= stepca 90.4% (Bundle L.B closure) awsacmpca 83.5% (existing tests; entrust-style retry edges remain) googlecas 83.4% (existing tests; OAuth2 token retry edges remain) Pattern per failure-mode test ================= - httptest.NewServer with selective handlers for /sys/health, /v1/ca, /ssl/v1/types etc. so ValidateConfig succeeds before the failure-mode HTTP call - 403 / 404 / 5xx / malformed-JSON / missing-PEM / invalid-base64 branches per connector - Status variants for GetOrderStatus dispatch arms (pending / processing / rejected / denied / unknown → fallback) - Where applicable: malformed cert PEM / bad CSR base64 / no DNSSolver / nil revocation reason Audit deliverables ================= - gap-backlog.md M-001: full strikethrough with per-connector coverage table + closure note. CLOSED (target-met-on-average) rather than (all ≥85%) — entrust 81.2% and awsacmpca/googlecas 83.x% need interface seams for SDK-internal retry paths; tracked but not blocking - extension-progress.md: N.A/B-extended marked DONE Closes (target-met-on-average): M-001 Bundle: N.A/B-extended (Coverage Audit Extension)	2026-04-27 21:35:01 +00:00