Let applications contribute template functions

[joshdrake]

A certificate template can only call the functions this library provides, and some of what a CA wants to put in a template is knowledge this library doesn't have and shouldn't acquire. There's currently no way to supply one: WithTemplate builds its function map internally, and it's reached through provisioners the CA constructs for itself, so no call path exists along which a function could be passed down.

RegisterTemplateFunc is that path.

x509util.RegisterTemplateFunc("cel", func(expr string, data any) (any, error) {
    // the application's own expression evaluator, over types it knows about
})

{{ cel "device.serial" $ | toJson }}

x509util and sshutil each keep their own registry, so registering for one kind of certificate doesn't silently affect the other, and an application wanting a function in both asks for both.

What it refuses

Shadowing a built-in. A template calling toJson or fail has to get this library's implementation; a registry that allowed the substitution would make a template's meaning depend on which packages a binary happened to link. Duplicate names, non-functions, and names that aren't Go identifiers are refused for the same reason — better an error at start-up than a template that parses and does something else.

The $ convention

A registered function receives only its own arguments, as any template function does. One that needs the data being rendered takes it as a parameter and the template supplies it with $ — which is the value the template was executed with wherever it appears, unlike the dot, which a range block rebinds. There's a test covering exactly that case.

Notes

• No new dependencies. Two files modified (net −6 lines), four added.
• Register during start-up, not lazily: text/template resolves function names at parse time, so a template rendered before the function is registered fails to parse. The doc comment says so, and a test demonstrates it.
• Full go test ./... passes, including -race.

Why this rather than a CEL environment in the library

This replaces #1116, which took the other approach — a public CEL package here, with an extension registry. That put cel-go in this library's public API to serve one embedder's needs. This is the smaller seam: crypto gains a way to accept a function and stays out of the expression business entirely, and the CEL machinery lives with the application that knows what a device is.

🤖 Generated with Claude Code

https://claude.ai/code/session_016N6LAjGgci2KLKYDbdWVcw

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[maraino]

LGTM, replace feels a little overkill