Skip to content

Merge branch 'v0.7.x' into develop#614

Open
kaidaguerre wants to merge 7 commits into
developfrom
merge-v0.7.x-into-develop
Open

Merge branch 'v0.7.x' into develop#614
kaidaguerre wants to merge 7 commits into
developfrom
merge-v0.7.x-into-develop

Conversation

@kaidaguerre
Copy link
Copy Markdown
Contributor

Brings v0.7.x release line (v0.7.4 security release) forward to develop. Closes Vanta SLA finding for pgx CVE-2026-41889 on default branch.

Conflict resolved

  • .github/workflows/01-tailpipe-release.yaml: same SHA, took v0.7.x's more-specific version comment (v3.12.0 vs v3).

)

pipe-fittings v2.9.1 adds an anonymous retry to OCI pulls when stored
GHCR credentials (from ~/.docker/config.json) are rejected. Without
this, an expired or revoked PAT causes tailpipe plugin install to
fail with an opaque 403 even when the image is publicly pullable.

Also picks up the pipe-fittings dependabot security sweep and GH
Actions hardening from v2.9.0.
turbot org requires all GitHub Actions to be pinned to full-length
commit SHAs. The release workflow had one unpinned reference which
caused 'Build and Release Tailpipe' to fail immediately on dispatch.
The Tag Release step runs 'git push origin $VERSION' via the default
github-actions[bot] token. Without an explicit permissions block the
token is read-only (org default), causing:

  remote: Permission to turbot/tailpipe.git denied to github-actions[bot].
  fatal: ... error: 403

Mirrors the permissions block steampipe's release workflow already has.
* Bump pgx to v5.9.2 + Go to 1.26.1 (CVE-2026-41889)

CVE-2026-41889 affects github.com/jackc/pgx/v5 below v5.9.2. pgx is an
indirect (compile-only) dependency of tailpipe; no tailpipe code calls
the pgx API. pgx v5.9.2 requires Go >= 1.25, so the Go toolchain is
bumped to 1.26.1 alongside the dependency pin.

Changes:
- go.mod: go directive 1.24.0 -> 1.26.1
- go.mod/go.sum: github.com/jackc/pgx/v5 v5.6.0 -> v5.9.2 (// indirect),
  plus transitive jackc/pgservicefile and jackc/puddle/v2 bumps from
  go mod tidy
- .github/workflows/10-test-lint.yaml: go-version 1.23 -> 1.26.1
- .github/workflows/11-test-acceptance.yaml: go-version 1.23 -> 1.26.1
  and 1.22 -> 1.26.1
- .github/workflows/01-tailpipe-release.yaml: go-version 1.23 -> 1.26.1

Verified: go build ./... clean; go test ./... pass (7 packages ok,
0 fail, 13 no test files) on go1.26.1.

Refs #607

* Fix Test Linting: migrate to golangci-lint v2 for go1.26 support

The pinned [email protected] with version: latest resolves
golangci-lint v1.64.8, which is built with go1.24 and hard-refuses any
module targeting a higher Go version:

  can't load config: the Go language version (go1.24) used to build
  golangci-lint is lower than the targeted Go version (1.26.1)

The Go 1.26.1 bump in this PR therefore breaks the Test Linting job.
The golangci-lint v1.x line is end-of-life and will never ship a
go1.26-built binary, so the fix is to move to the v2 line:

- 10-test-lint.yaml: golangci-lint-action v6.5.2 -> v9.2.0,
  version latest -> v2.11.4 (built with a go1.26-capable toolchain)
- .golangci.yml: migrate v1 -> v2 config format (via the official
  golangci-lint v2 migrate tool), preserving prior behaviour:
  - staticcheck excludes ST*/QF* (stylecheck + quickfix were merged
    into staticcheck in v2 and were never enforced before)
  - gosec excludes G118/G122/G706 (new rules absent from the
    previously pinned gosec ruleset; flag pre-existing code only)
  - nolintlint exclusion for now-unused gosec directives

Verified: untouched origin/v0.7.x lints clean with the old binary and
the PR head fails identically to CI; with this fix the PR head lints
clean (0 issues) under golangci-lint v2.11.4 built with go1.26.1.

Refs #607

* Restore golangci-lint v1 parity: unpin version, re-enable gosec G101/G602

Revert the golangci-lint version pin from v2.11.4 back to latest in
.github/workflows/10-test-lint.yaml so CI tracks the newest v2 release
(the [email protected] major bump is retained — it is required
for go1.26 support and is unrelated to the version pin).

Remove gosec G101 (hardcoded credentials) and G602 (slice bounds out of
range) from the .golangci.yml gosec excludes list. A lint-coverage parity
audit proved these two rules WERE enforced under the pre-bump v1 toolchain
(golangci-lint v1.64.8 / gosec v2.22.2) and excluding them was the only
real reduction in enforced security/safety coverage introduced by the
v1->v2 migration. Re-enabling them restores true parity.

All other migrated config is left exactly as-is (verified true parity by
the audit): the v1->v2 format conversion, the staticcheck -ST*/-QF*
excludes (stylecheck was disabled and QF did not exist under v1), the
gosec G118/G122/G706 excludes (never existed in v1's gosec), and the
nolintlint unused-directive message suppression (a spurious-message
suppression, not a coverage change).

Verified: golangci-lint v2.11.4 built from source with GOTOOLCHAIN=go1.26.1
run on the modified head reports 0 issues (no G101/G602/anything).

* Disable noisy govet inline analyzer (golangci-lint v2.12.2 false positives)
Comprehensive security remediation for tailpipe v0.7.4, superseding the
CHANGELOG-only PR #610.

- pgx/v5 v5.6.0 -> v5.9.2 (CVE-2026-41889, landed via #608)
- Go 1.24.0 -> 1.26.1 (landed via #608)
- go-jose/go-jose/v4 v4.1.3 -> v4.1.4 (indirect, via go-spiffe/grpc-xds)
- go.opentelemetry.io/otel/sdk + siblings v1.40.0 -> v1.43.0 (indirect, via tailpipe-plugin-sdk grpc)

go mod tidy applied. Build and full test suite pass.

pgproto3/v2 (GHSA-jqcq-xjh3-6g23 / CVE-2026-32286) not in module graph;
no action required.
…evelop

# Conflicts:
#	.github/workflows/01-tailpipe-release.yaml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants