Skip to content

Security: upgrade vulnerable deps so PR #274 (govulncheck + gitleaks CI gates) can land #346

Description

@zoetaka38

Handoff from the open-git PR-drain effort

PR #274 ([] Add govulncheck and gitleaks jobs to .github/workflows/ci.yml, branch feature/019f0d821e5d-019f0d821e5d) was intentionally left unmerged during the bulk PR remediation. Merging it as-is would add a permanently-RED CI gate, because the new govulncheck job fails immediately against vulnerabilities already present in main's dependencies.

PR: #274

Why it can't just be merged

govulncheck ./... on main exits 3 with 19 called-vulnerability findings in existing deps. Adding the gate without first fixing these makes every subsequent PR red. Required dependency upgrades:

  • golang.org/x/crypto v0.51.0 → v0.52.0 (9 vulns)
  • github.com/go-git/go-git/v5 v5.13.2 → v5.17.1 (3 vulns; major-ish API bump — needs care, go-git is used in the git-hosting core)
  • github.com/cloudflare/circl v1.3.7 → v1.6.3 (2)
  • github.com/go-viper/mapstructure/v2 v2.2.1 → v2.4.0 (2)
  • github.com/golang-jwt/jwt v3.2.2 → v5 (GO-2025-3553) — note it's also pulled transitively via labstack/echo v4.12.0, so a v3→v5 bump in this PR does not fully remove it
  • Go stdlib net/textproto, crypto/x509 — need a CI Go version bump

Additional caveat: PR #274 also scope-creeps a jwt v3→v5 upgrade mixed in with the CI change.

Suggested approach

  1. Do the dependency upgrades as their own focused PR(s) first — especially the go-git v5.13→v5.17 API bump carefully (it touches the git-hosting core), and bump the CI Go version for the stdlib findings.
  2. Address the transitive jwt-via-echo path (bump labstack/echo or pin).
  3. Rebase [] Add govulncheck and gitleaks jobs to .github/workflows/ci.yml #274 on the upgraded main, drop the scope-crept jwt change from it, resolve its conflict (currently DIRTY), and confirm govulncheck/gitleaks/brand-check/license-check all pass.
  4. Then merge [] Add govulncheck and gitleaks jobs to .github/workflows/ci.yml #274 so the security gates are green from day one.

Acceptance criteria

Context: full blocker analysis is also posted as a comment on PR #274.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions