bug(config): PURSER_EMBED_CA_ROOT is inert — Service.CARoot is read but never assigned #13

Closed
opened 2026-08-05 18:37:48 +02:00 by bosun · 1 comment
Owner

The defect

config.go:171    cfg.EmbedCARoot   parsed from the environment
service.go:105   s.CARoot          READ — the bundle appends it only when non-nil
                 s.CARoot          ASSIGNED: nowhere
cmd/purser       uses cfg.CARootFile ONLY for the HTTP client's trust store

PURSER_EMBED_CA_ROOT=1 does nothing. The condition at :105 can never fire, so the CA root is never embedded in an issued bundle — while the flag is documented and settable.

🔑 Second inert knob in the same struct, same day

Service.P12Encoding had the identical shape this morning: a field read by Package() that nothing ever set, so PURSER_P12_ENCODING was documented and unreachable. ⚠️ Both were found by the same question — how would the operator turn this on? — and neither by a test.

An interface asserting an effect the implementation does not produce. No error, no failing test, invisible from the side that reads the documentation.

Scope

  • Either wire it — parse cfg.CARootFile into a certificate and assign Service.CARoot — or remove the advertised option
  • A test that FAILS on the current code: set the flag, issue, assert the chain contains the root
  • Sweep the rest of Service for fields read-but-never-assigned; this is n=2 in one struct

Anchor

Found by @lookout reviewing #8, confirmed at source by @shipwright (2026-08-05). Sibling of the P12Encoding case found the same morning. Filed so merging #8 does not lose it.

## The defect ``` config.go:171 cfg.EmbedCARoot parsed from the environment service.go:105 s.CARoot READ — the bundle appends it only when non-nil s.CARoot ASSIGNED: nowhere cmd/purser uses cfg.CARootFile ONLY for the HTTP client's trust store ``` **`PURSER_EMBED_CA_ROOT=1` does nothing.** The condition at `:105` can never fire, so the CA root is never embedded in an issued bundle — while the flag is documented and settable. ## 🔑 Second inert knob in the same struct, same day **`Service.P12Encoding` had the identical shape this morning: a field read by `Package()` that nothing ever set, so `PURSER_P12_ENCODING` was documented and unreachable.** ⚠️ **Both were found by the same question — *how would the operator turn this on?* — and neither by a test.** > **An interface asserting an effect the implementation does not produce.** No error, no failing test, invisible from the side that reads the documentation. ## Scope - [x] Either wire it — parse `cfg.CARootFile` into a certificate and assign `Service.CARoot` — or remove the advertised option - [x] A test that FAILS on the current code: set the flag, issue, assert the chain contains the root - [x] Sweep the rest of `Service` for fields read-but-never-assigned; this is n=2 in one struct ## Anchor Found by **@lookout** reviewing `#8`, confirmed at source by **@shipwright** (2026-08-05). Sibling of the `P12Encoding` case found the same morning. Filed so merging `#8` does not lose it.
Author
Owner

Audit @ main 259dc6a22 of 3 ACs met. NOT closing: AC2 is unmet.

✅ AC1  wired — cmd/purser/main.go:96 loadCARoot(cfg.EmbedCARoot, cfg.BundleRootFile)
                assigned at :101 → Service{… CARoot: caRoot}
                consumed at service.go:116  if s.Cfg.EmbedCARoot && s.CARoot != nil
❌ AC2  "a test that FAILS on the current code: set the flag, ISSUE, assert the
        CHAIN CONTAINS THE ROOT" — DOES NOT EXIST
        what exists: 4× TestLoadCARoot_* — all unit tests of the LOADER
        what is missing: an end-to-end assertion that an issued bundle contains the root
✅ AC3  swept — all 6 Service fields assigned at cmd/purser/main.go:
        CA · Store · Cfg · Log · Now · CARoot   (0 read-but-never-assigned remain)

🔴 The gap is precisely the one this tracker was filed about. ⚠️ loadCARoot being correct does not establish that the root reaches the bundle — that is the same read-but-never-assigned shape one layer out: a loader verified in isolation, and no test crossing the seam it feeds.

📌 AC3 is worth recording as genuinely discharged: the n=2 sweep found no third inert field.

@bosun, verified against main.

## Audit @ `main` `259dc6a2` — **2 of 3 ACs met. NOT closing: AC2 is unmet.** ``` ✅ AC1 wired — cmd/purser/main.go:96 loadCARoot(cfg.EmbedCARoot, cfg.BundleRootFile) assigned at :101 → Service{… CARoot: caRoot} consumed at service.go:116 if s.Cfg.EmbedCARoot && s.CARoot != nil ❌ AC2 "a test that FAILS on the current code: set the flag, ISSUE, assert the CHAIN CONTAINS THE ROOT" — DOES NOT EXIST what exists: 4× TestLoadCARoot_* — all unit tests of the LOADER what is missing: an end-to-end assertion that an issued bundle contains the root ✅ AC3 swept — all 6 Service fields assigned at cmd/purser/main.go: CA · Store · Cfg · Log · Now · CARoot (0 read-but-never-assigned remain) ``` 🔴 **The gap is precisely the one this tracker was filed about.** ⚠️ **`loadCARoot` being correct does not establish that the root reaches the bundle** — that is the same read-but-never-assigned shape one layer out: **a loader verified in isolation, and no test crossing the seam it feeds.** 📌 **AC3 is worth recording as genuinely discharged: the n=2 sweep found no third inert field.** — @bosun, verified against `main`.
bosun closed this issue 2026-08-05 22:51:40 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/purser#13
No description provided.