ko build -toolexec opt-in flag to allow use in git workflow

Problem

ko build rejects -toolexec on every path: CLI flags, .ko.yaml (env/flags), and GOFLAGS in the build environment (the last one closed by #1618, shipped in v0.19.0):

could not create env for ...: cannot set -toolexec=<path> via GOFLAGS
environment variable

We understand the security reasons for excluding -toolexec (#752), but we think it would be useful to have a way of using it in the context of a git workflow (where Github Actions specifically requires approval to run CI from an untrusted user).

The current "no -toolexec” restriction doesn't distinguish "the repo being built asked for this" (untrusted) from "the person/CI job invoking ko build asked for this" (trusted — they already control the whole build). ko already draws this line elsewhere: KO_GO_PATH is only read from the invoking shell's environment, never from .ko.yaml, so it's an operator-only channel today. A -toolexec opt-in reachable only from the ko build command line would sit at that same trust tier without reopening what #1618 closed.

Concrete tools this blocks

-toolexec is the standard, documented Go mechanism for compile-time instrumentation without touching source. Real tools depend on it:

• OpenTelemetry Go Compile-Time Instrumentation (https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation), which uses -toolexec to inject tracing into an app and its dependencies.
• Tobari (https://github.com/goccy/tobari) — a coverage-instrumentation tool using the same mechanism.

Anyone building images with ko who wants either gets the error above, with no supported way around it.

Proposed shape

A CLI flag on ko build, e.g. -toolexec=<path>, following the precedent of --ldflags from #1675 — a repeatable flag that exists specifically because GOFLAGS is the wrong tool for values like this. To stay inside the current trust boundary: - settable only via the command line, never via .ko.yaml or GOFLAGS - everything currently rejected in .ko.yaml/GOFLAGS stays rejected there — additive, not a relaxation.

I'd be happy to put up a PR if this shape (or a variant) is welcome, but I figure it's best to raise it as a design question first.

Related

• #1620 — the report that led to the GOFLAGS restriction
• #752 — original 2022 PR blocking -toolexec outright
• #1636 — closed PR extending the block to -overlay/-modfile. Different flags, same shape of question.