Audit the forked Scriggo runtime as a component: sandbox posture, upstream divergence, maintenance burden

Problem

HAPTIC executes operator-authored template code in-process on the controller's own goroutines, via a fork of Scriggo (gitlab.com/haproxy-haptic/scriggo v0.0.0-20260809131558-5dfe5ec9655e, go.mod:20). pkg/templating/engine_scriggo.go:179 sets AllowGoStmt: true so templates can spawn goroutines (go MacroName()). The fork has never been reviewed as a component: nobody has written down what the sandbox does and does not contain, how far the fork has drifted from upstream, or who carries it if upstream moves.

Why it matters

The trust boundary is not obvious. A template comes from a HAProxyTemplateConfig/HAProxyTemplateLibrary — an object anyone with RBAC write access on the controller's namespace can edit, and that HAPTIC also renders during admission on the request path of every opted-in Ingress/HTTPRoute create. So template code runs in the controller process, with the controller's service account in scope, before an operator has necessarily reviewed it. AllowGoStmt: true widens that: a template can create goroutines the render's context cannot cancel. There is no stated answer today to "can a template exhaust the controller's memory, wedge a render, or reach the filesystem", and no answer to "if upstream Scriggo ships a security fix, how do we take it".

What a good answer looks like

  • A written sandbox posture: for each capability (native function registry, go statements, os/io reachability, unbounded allocation, unbounded loop, panic containment, render timeout enforcement) state contained / not contained / not applicable, with a code reference.
  • A git diff summary against the upstream commit the fork branched from: file count, line count, and whether any divergence touches the compiler, the VM, or the package-import allowlist.
  • A stated maintenance answer: who rebases, what the cadence is, and how a CVE in upstream Scriggo would be noticed at all (Renovate tracks the digest, but a digest bump is not a security signal).
  • A decision on AllowGoStmt: true — the comment says "Enable parallel template rendering"; the chart's own libraries should be checked for whether they actually use it.

Suggested first step

git -C <scriggo fork> log --oneline <upstream-base>..HEAD plus git diff --stat to size the divergence, then grep the bundled chart (charts/haptic/charts/**/*.yaml) for go statements to establish whether AllowGoStmt is load-bearing or vestigial. If vestigial, turning it off is a one-line, testable narrowing.

Filed from an architecture review of the controller (2026-08-10, branch round6/scan @ 4afd3efc). This is a coverage gap the review could not close, not a confirmed defect — the review recorded what it did not audit so the unexamined areas are not mistaken for verified ones.