Request: tag v1.0.2 — main carries security dependency bumps with no Go source changes

[ramesh82]

Request

Could you cut a v1.0.2 tag from current main?

main already contains security dependency bumps that v1.0.1 does not, and the delta is dependency and docs changes only — no Go source changes, so tagging should be very low risk:

$ git diff --stat v1.0.1..origin/main -- '*.go' ':!go.mod' ':!go.sum'
(empty)

$ git log --oneline v1.0.1..origin/main
43ed5f4 Docs: updates content and reorganizes content for better readability (#200)
65a24cc fix(security/unknown/): update module golang.org/x/text to v0.39.0 [security] (#194)
eb29e5c fix(security/high/): update module google.golang.org/grpc to v1.82.1 [security] (#195)

Why it matters

Comparing the published v1.0.1 release binary against main:

Module	v1.0.1	main (43ed5f4)
golang.org/x/net	v0.53.0	v0.56.0
golang.org/x/crypto	v0.50.0	v0.53.0
golang.org/x/text	v0.36.0	v0.39.0
google.golang.org/grpc	v1.80.0	v1.82.1

The x/net gap is the one that matters most: GO-2026-5026 (golang.org/x/net/idna) is fixed in 0.55.0, so v1.0.1's v0.53.0 is affected. And x/net/idna is genuinely linked into the release binary, not just present in the module graph:

$ unzip -q lambda-promtail-v1.0.1.zip && go tool nm bootstrap | grep -c 'x/net/idna'
74

x/crypto v0.50.0 is also below the 0.52.0 fix for GO-2026-5005. That one is ssh/agent and is not linked (0 symbols), so it isn't reachable — but SBOM-based scanners such as AWS Inspector report on module versions rather than reachability, so it still surfaces as a finding for anyone deploying the published zip.

Two smaller things while you're in here

1. The bucket's default key still points at v1.0.0. aws-alb-logs.yaml defaults S3KeyName to lambda-promtail.zip, and that object is still the v1.0.0 build:

$ aws s3 ls --no-sign-request s3://grafanalabs-cf-templates/lambda-promtail/
2026-03-14 07:21:20   27787309 lambda-promtail-v1.0.0.zip
2026-07-23 22:52:58   27032190 lambda-promtail-v1.0.1.zip
2026-03-14 03:48:58   27787291 lambda-promtail.zip     <-- == v1.0.0

So anyone deploying the template with defaults gets the oldest release (go1.24.13, x/net v0.47.0). Refreshing lambda-promtail.zip as part of the release job would fix that. Related to #112.

2. The release build pins an older Go patch than intended. release.yml uses go-version-file: go.mod, which resolves to exactly go 1.25.7. That toolchain's own stdlib has since-fixed vulnerabilities — govulncheck -mode=binary against the v1.0.1 zip reports fixes landing in go1.25.9 through go1.25.12 (archive/tar, os root escape, net/http/httputil, mime). Note this differs from the Dockerfile, which is on golang:1.26-alpine. Building the released zip on the latest 1.25.x (or adding a toolchain directive) would close those without any language-version change.

Aside: #176 looks blocked

Not part of this request, but govulncheck flags 4 findings against prometheus/prometheus@v0.308.1, and the bump in #176 appears blocked by an upstream removal rather than just being stale:

github.com/grafana/loki/v3/pkg/util imports
	github.com/prometheus/prometheus/tsdb/errors: module
	github.com/prometheus/prometheus@latest found (v0.313.2), but does not
	contain package github.com/prometheus/prometheus/tsdb/errors

Looks like it needs a change in grafana/loki first.

Happy to open a PR for any of the above if that helps.