security: bump Go toolchain to 1.27.1 and vulnerable deps for v0.1.14

[adidavid014]

Summary

A customer's syft/grype scan of the v0.1.13 protoc-gen-openapi-linux-amd64 binary (built with go1.25.8) flagged:

• Go stdlib CVEs fixed in Go 1.25.13 / 1.26.6
• Outdated golang.org/x/net (<0.55.0) and google.golang.org/grpc (<1.82.2) pulled in transitively

This PR is dependency/toolchain only — no generator behavior changes.

Changes

1. Go toolchain: bumped to go1.27.1 (latest stable, well past the 1.26.6/1.25.13 security fixes)
   • .github/workflows/release.yml: setup-go go-version: "1.27.1" (was ^1.20)
   • .github/workflows/go.yml: same bump, for consistency
   • go.mod: added toolchain go1.27.1 and the go directive was auto-raised to 1.26.0 by go get -u
2. Dependencies: ran go get -u golang.org/x/net golang.org/x/crypto golang.org/x/image google.golang.org/grpc google.golang.org/protobuf (only x/net and grpc were actually present in the module graph — x/crypto/x/image are not dependencies of this module) + go mod tidy
   • golang.org/x/net: v0.8.0 → v0.59.0 (≥0.55.0 ✅)
   • google.golang.org/grpc: v1.54.0 → not directly imported by any package in this module, so go mod tidy dropped it from the explicit require list; the module graph still resolves it to v1.79.3 via google.golang.org/genproto's own go.mod, but it is not linked into the shipped binary (confirmed via go list -deps ./cmd/protoc-gen-openapi/... and the go version -m output below has no grpc entry at all)
   • google.golang.org/protobuf: v1.30.0 → v1.36.12
   • github.com/golang/protobuf: v1.5.3 → v1.5.4
   • golang.org/x/crypto, golang.org/x/image: not present in the module graph (nothing to bump)
3. plugins/environment.go: fixed a pre-existing non-constant format string passed to fmt.Fprintf in the CLI usage message. It was always latent, but only surfaces as a go vet build failure (which blocks go test) once go.mod's language version moves to 1.21+. Output text is byte-for-byte identical ("%s is a gnostic plugin.\n" vs programName+" is a gnostic plugin.\n").

Why go.sum shrank by ~1500 lines: the old pinned google.golang.org/genproto@v0.0.0-20230526... (a 2023 pseudo-version from before that repo was split apart) has a go.mod that directly requires ~150 individual cloud.google.com/go/* service submodules, none of which this project ever imports — plus their own onward transitive deps (gonum plotting, PDF libs, x/mobile, x/exp, envoy xds, etc.). None of that was ever compiled into any binary here; go.sum just has to record checksums for everything in the module graph. The 2026-era replacements (google.golang.org/genproto/googleapis/api and .../rpc) were split out of that monorepo years ago and have minimal go.mods (just grpc/protobuf/a few x/* indirects), so upgrading collapsed the graph accordingly. Nothing that was actually part of the built binary changed shape — verify with go list -deps ./cmd/protoc-gen-openapi/... before/after.

Verification

go build ./... and go vet ./... — clean:

$ go build ./...
$ go vet ./...
(no output, exit 0)

go test ./... — all packages pass except two pre-existing, environment-dependent failures that I verified also fail on main before this change with the same local toolchain (missing/mismatched local protoc/diff behavior, not code):

• cmd/protoc-gen-openapi (protoc-invoking tests) — fails the same way on main
• extensions (TestExtensionHandlerWithLibraryExample) — fails the same way on main

govulncheck ./...:

No vulnerabilities found.

Built the linux/amd64 release binary exactly as release.yml does and inspected it:

$ GOOS=linux GOARCH=amd64 go build -trimpath -ldflags="-s -w" -o dist/protoc-gen-openapi-linux-amd64 ./cmd/protoc-gen-openapi
$ go version -m dist/protoc-gen-openapi-linux-amd64
dist/protoc-gen-openapi-linux-amd64: go1.27.1
	path	github.com/fern-api/protoc-gen-openapi/cmd/protoc-gen-openapi
	mod	github.com/fern-api/protoc-gen-openapi	v0.1.13+dirty	
	dep	github.com/google/gnostic-models	v0.6.9-0.20230804172637-c7be7c783f49	h1:0VpGH+cDhbDtdcweoyCVsF3fhN8kejK6rFe/2FFX2nU=
	dep	google.golang.org/genproto/googleapis/api	v0.0.0-20260706201446-f0a921348800	h1:admdQBe8jR3VWhBsUrAOaF2Qw6K/+p5pSm1GN8+6Fw4=
	dep	google.golang.org/genproto/googleapis/rpc	v0.0.0-20260921155816-b14227669459	h1:b0xCahf3FK2m2Cv0p4vTozGPWncCvLfwV86UNg8xWU8=
	dep	google.golang.org/protobuf	v1.36.12	h1:pJOKDDOyeXErUroCihFAd5LQuwXBSpVnKGrj5o/fwxc=
	dep	gopkg.in/yaml.v3	v3.0.1	h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=
	build	-buildmode=exe
	build	-compiler=gc
	build	-trimpath=true
	build	CGO_ENABLED=0
	build	GOARCH=amd64
	build	GOOS=linux
	build	vcs=git

Confirms: built with go1.27.1, and golang.org/x/net, golang.org/x/crypto, golang.org/x/image, and google.golang.org/grpc are not present in the shipped binary at all (they were never linked in — only the Go toolchain's own vendored copies of x/net/x/crypto inside net/http/crypto/tls were relevant to the syft flag, and those are now updated simply by building with go1.27.1). Repeated the same build/inspect for linux/arm64 with identical results (go1.27.1, same dep set).

Release steps for v0.1.14 (unchanged asset names)

fern-platform's servers/self-hosted/Dockerfile.base downloads protoc-gen-openapi-linux-amd64 / protoc-gen-openapi-linux-arm64 by exact name, so this release must keep producing those same filenames (it does — release.yml is unchanged in that respect).

1. Merge this PR to main.
2. git checkout main && git pull
3. git tag v0.1.14 && git push origin v0.1.14
4. The Release workflow (.github/workflows/release.yml) triggers on the v* tag push, builds all 6 platform binaries with go1.27.1, and publishes them as a GitHub Release via softprops/action-gh-release, producing (among others):
   • protoc-gen-openapi-linux-amd64
   • protoc-gen-openapi-linux-arm64
     (same names as v0.1.13 — no Dockerfile.base change needed downstream)
5. Optionally re-run the customer's syft/grype scan against the new protoc-gen-openapi-linux-amd64 asset to confirm the flagged findings are gone.

---

Generated with Claude Code