bug(config): PURSER_EMBED_CA_ROOT is inert — Service.CARoot is read but never assigned #13
Labels
No labels
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
status/deferred
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/purser#13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The defect
PURSER_EMBED_CA_ROOT=1does nothing. The condition at:105can 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.P12Encodinghad the identical shape this morning: a field read byPackage()that nothing ever set, soPURSER_P12_ENCODINGwas documented and unreachable. ⚠️ Both were found by the same question — how would the operator turn this on? — and neither by a test.Scope
cfg.CARootFileinto a certificate and assignService.CARoot— or remove the advertised optionServicefor fields read-but-never-assigned; this is n=2 in one structAnchor
Found by @lookout reviewing
#8, confirmed at source by @shipwright (2026-08-05). Sibling of theP12Encodingcase found the same morning. Filed so merging#8does not lose it.Audit @
main259dc6a2— 2 of 3 ACs met. NOT closing: AC2 is unmet.🔴 The gap is precisely the one this tracker was filed about. ⚠️
loadCARootbeing 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.