Carry every configured ETSI field into the TSL registry

[leifj]

The bug

Configuring the ETSI registry from a config file built etsi.TSLConfig without copying TSLURLs across — nor FollowRefs, MaxRefDepth, UserAgent, AllowNetworkAccess or FetchTimeout.

A config file with tsl_urls therefore produced a registry with nothing to load, and the process exited with:

no trust data loaded - configure CertBundle, TSLFiles, or TSLURLs

...while the operator was looking at a file that plainly configures TSLURLs. The message points at the configuration rather than at the code that ignored it, so the natural reaction is to doubt the key name or the URL. The lote registry's config path has no such gap, which makes the ETSI one look like the operator's mistake.

Only tsl_files worked, and only by accident of being one of the fields that was mapped.

Why nothing caught it

A dropped field does not produce a wrong value, it produces the zero value — an empty slice, a false bool, a zero duration. Every one of those is a plausible default, so nothing downstream looks wrong until the registry has no trust data at all.

The mapping is now its own function so it can be tested, and the test asserts every field individually rather than the one that happened to be noticed. Reverting the fix fails it on all five:

TSLURLs = [], want [https://registrar.example.org/tsl.xml]
FollowRefs was not carried across
MaxRefDepth = 0, want 4
AllowNetworkAccess was not carried across
UserAgent = "", want "test-agent/1.0"

FetchTimeout follows the LoTE registry's existing pattern: parse the duration, warn and leave the default on a bad value. A test pins that an unparseable value leaves the zero so the registry applies its default, rather than propagating "no timeout".

Verified against a real deployment

An ETSI registry configured with tsl_urls now fetches and parses over HTTP, where before it refused to start:

Configuring ETSI TSL registry from config file
g119612: Parsed TSL from http://wrpac-registrar:8080/tsl.xml with 2 trust service providers
ETSI TSL registry registered from config

The list is one published by siros-wrpac-tool. go test ./cmd/... ./pkg/config/... ./pkg/registry/etsi/... and golangci-lint are clean.

Found while wiring sirosid-dev to a TSL; that stack currently works around this with tsl_files and a bind mount, which can go once this is released.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DWj5aAxqWjEm5ESCX4P1hk

[Copilot]

🟢 Approval recommended

The change directly addresses a concrete config-mapping bug with low risk and clear behavior, with only a minor consistency nit noted.

Pull request overview

This PR fixes ETSI TSL registry configuration mapping when configuring from a YAML config file by ensuring all relevant ETSIRegistryConfig fields are carried into etsi.TSLConfig, preventing “no trust data loaded” failures when tsl_urls is set.

Changes:

• Refactors ETSI config-to-registry mapping into a dedicated etsiTSLConfig(...) helper.
• Ensures TSLURLs, FollowRefs, MaxRefDepth, UserAgent, AllowNetworkAccess, and FetchTimeout are propagated from file config into the registry config (with duration parsing + warning on invalid values).

File summaries

File	Description
cmd/gt/main.go	Extracts ETSI TSL config mapping into a testable helper and carries previously-dropped ETSI fields into etsi.TSLConfig.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud