mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-12 19:40:27 +00:00
8564e2fcd688d358c48f39d3a4b8bc8a008eaf7c
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
|
||
|
shankar0123
|
ece15cb457 |
vault, digicert: migrate Token / APIKey to *secret.Ref (Bundle I Phase 3)
Closes Top-10 fix #2 of the 2026-05-03 issuer-coverage audit (see cowork/issuer-coverage-audit-2026-05-03/RESULTS.md). Pre-fix, vault.Config.Token and digicert.Config.APIKey were plain string fields. Practical impact: 1. GET /api/v1/issuers responses marshalled the credential into the JSON body. An acquirer's procurement engineer running 'curl /api/v1/issuers | jq' saw the token / API key in plain text on screen. 2. DEBUG-level HTTP request logging printed the credential header verbatim. 3. A heap dump of the running server contained the credential as readable bytes for the lifetime of the process. Bundle I from the 2026-05-01 audit closed this for AWSACMPCA, EJBCA, GlobalSign, Sectigo (Phase 1+2). Vault and DigiCert were left out. This commit ports the same migration onto them. Mechanics: - Config.Token / Config.APIKey type changed from 'string' to '*secret.Ref'. UnmarshalJSON of a JSON string populates the Ref via NewRefFromString — operator config files are unchanged. - Every header-write call site routed through Ref.Use, with the byte buffer zeroed after the callback returns. Vault: 3 sites (IssueCertificate, RevokeCertificate, GetCACertPEM). DigiCert: 5 sites (ValidateConfig, IssueCertificate, RevokeCertificate, pollOrderOnce, downloadCertificate). - ValidateConfig nil-checks switch from 'cfg.Token == ""' to 'cfg.Token.IsEmpty()' (mirrors Sectigo's existing pattern). - Tests migrated: every Config{Token:"..."} → Config{Token: secret.NewRefFromString("...")}. The 'json.Marshal(config) → ValidateConfig(rawConfig)' round-trip pattern in DigiCert's ValidateConfig_Success test is now broken by the redact-on-marshal contract — switched that one to construct the rawConfig as a JSON literal (mirrors Sectigo's existing test pattern). - Two new tests pin the redact-on-marshal contract: - TestVault_Config_TokenMarshalsAsRedacted (vault_redact_test.go) - TestDigiCert_Config_APIKeyMarshalsAsRedacted (digicert_redact_test.go) Both assert the marshaled JSON contains '"[redacted]"' and does NOT contain the plaintext bytes. Operator-visible: GET /api/v1/issuers responses for type=vault and type=digicert now show the credential as '[redacted]'. Existing config files keep working — the Ref unmarshal accepts strings. CHANGELOG note: certctl/CHANGELOG.md is intentionally not hand-edited; release notes are auto-generated from commit messages between consecutive tags. This commit's message body is the release-note artifact. Verified locally: - gofmt clean across the repo. - go vet ./... clean across the repo. - go test -race -count=1 -short ./internal/connector/issuer/vault/... ./internal/connector/issuer/digicert/... ./internal/secret/... green. Audit reference: cowork/issuer-coverage-audit-2026-05-03/ RESULTS.md Top-10 fix #2. |
||
|
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)
|