mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-11 06:48:52 +00:00
shankar0123
5dc698307b
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.
59 lines
2.9 KiB
Go
59 lines
2.9 KiB
Go
package intune
|
|
|
|
// SCEP RFC 8894 + Intune master bundle Phase 8.5 (originally) +
|
|
// EST RFC 7030 hardening master bundle Phase 2.1 (extraction).
|
|
//
|
|
// TrustAnchorHolder + NewTrustAnchorHolder were extracted to
|
|
// internal/trustanchor.Holder + trustanchor.New so the EST mTLS sibling
|
|
// route (Phase 2 of the EST hardening bundle) and the Intune dispatcher
|
|
// can share the same SIGHUP-reloadable PEM bundle primitive. A single
|
|
// SIGHUP now rotates: server TLS cert (cmd/server/tls.go), every Intune
|
|
// trust anchor (this package's existing wiring), AND every EST mTLS
|
|
// per-profile client-CA bundle (the new sibling route) — exactly the
|
|
// design contract documented in the trustanchor package doc.
|
|
//
|
|
// The aliases below preserve every existing intune call site unchanged:
|
|
// - cmd/server/main.go declares `intuneTrustHolders []*intune.TrustAnchorHolder`
|
|
// + invokes `intune.NewTrustAnchorHolder(path, logger)`
|
|
// - internal/service/scep.go's SCEPService struct field
|
|
// `intuneTrust *intune.TrustAnchorHolder` (the type alias keeps this
|
|
// pointer-compatible with the original)
|
|
// - internal/scep/intune/trust_anchor_holder_test.go + the e2e tests
|
|
// that construct a holder via NewTrustAnchorHolder
|
|
//
|
|
// New callers SHOULD import internal/trustanchor directly — the
|
|
// trustanchor.Holder + trustanchor.New are the modern API. The intune
|
|
// aliases are preserved indefinitely for back-compat (no deprecation
|
|
// timeline; the cost of the two-line shim is trivial).
|
|
|
|
import (
|
|
"github.com/certctl-io/certctl/internal/trustanchor"
|
|
)
|
|
|
|
// TrustAnchorHolder is the SIGHUP-reloadable wrapper around a per-profile
|
|
// Intune Connector trust anchor pool.
|
|
//
|
|
// Aliased to trustanchor.Holder (extracted in EST RFC 7030 hardening
|
|
// Phase 2.1) so the EST mTLS sibling route + the Intune dispatcher share
|
|
// the same primitive. Existing callers compile unchanged because Go type
|
|
// aliases are pointer-compatible.
|
|
type TrustAnchorHolder = trustanchor.Holder
|
|
|
|
// NewTrustAnchorHolder loads the trust bundle and returns a holder.
|
|
// Aliased to trustanchor.New (extracted in EST RFC 7030 hardening
|
|
// Phase 2.1). Returns the same fail-loud error LoadTrustAnchor does on
|
|
// initial load — the startup gate at cmd/server/main.go is supposed to
|
|
// refuse boot when this fails. Subsequent Reload errors are non-fatal
|
|
// (logged + old pool retained).
|
|
//
|
|
// The logger is required (never nil); the caller passes a per-profile
|
|
// scoped logger so SIGHUP-reload events show the PathID for triage.
|
|
//
|
|
// Note: the original intune.NewTrustAnchorHolder set the holder's
|
|
// internal log label to "Intune trust anchor"; the extracted
|
|
// trustanchor.New defaults to "trust anchor". Existing intune callers
|
|
// that need the original label should call .SetLabelForLog("intune
|
|
// trust anchor (PathID=…)") on the returned holder. cmd/server/main.go
|
|
// does this in the per-profile Intune startup loop.
|
|
var NewTrustAnchorHolder = trustanchor.New
|