Just a heads up to inform you that prior to version 0.17.0, golang.org/x/net is subject to the following vulnerability: - CVE-2023-39325 - https://github.com/golang/go/issues/63417

Looks like the pull request has already been made: https://github.com/gin-gonic/gin/pull/3754 Any maintainer could look into this please? :pray:

Thanks!

Comment From: vyrwu

Bumping, breaks our DevSecOps pipelines.

Version: github.com/gin-gonic/gin v1.9.1

❯ govulncheck -C src/cmd .
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Using go1.21.2
 and govulncheck@v0.2.0 with vulnerability data from https://vuln.go.dev (last modified 2023-10-16 19:30:55 +0000 UTC).

Scanning your code and 434 packages across 79 dependent modules for known vulnerabilities...

Vulnerability #1: GO-2023-2102
    HTTP/2 rapid reset can cause excessive work in net/http
  More info: https://pkg.go.dev/vuln/GO-2023-2102
  Module: golang.org/x/net
    Found in: golang.org/x/net@v0.10.0
    Fixed in: golang.org/x/net@v0.17.0
    Example traces found:
      #1: src/cmd/main.go:89:16: cmd.main calls gin.Engine.Run, which eventually calls http2.Server.ServeConn

=== Informational ===

Found 1 vulnerability in packages that you import, but there are no call
stacks leading to the use of this vulnerability. You may not need to
take any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Vulnerability #1: GO-2023-1988
    Improper rendering of text nodes in golang.org/x/net/html
  More info: https://pkg.go.dev/vuln/GO-2023-1988
  Module: golang.org/x/net
    Found in: golang.org/x/net@v0.10.0
    Fixed in: golang.org/x/net@v0.13.0

Your code is affected by 1 vulnerability from 1 module and the Go standard library.

Comment From: mwillfox

This is also breaking our security pipeline. Seems like it needs to be resolved.

Comment From: kwenzh

the same trouble

Comment From: a-h

The security fix was merged in https://github.com/gin-gonic/gin/pull/3774 today, but not released yet.

Tests are failing https://github.com/gin-gonic/gin/actions/runs/6890660139/job/18744176853

I note that the tests are not testing the current Go version (Go 1.21), and the failing test is for a Go version that is no longer supported (Go 1.19). https://endoflife.date/go

There's a PR to fix that - https://github.com/gin-gonic/gin/pull/3693 - but that is failing too. The log is no longer available because it's so old.

However, reading back through the history, it seems like it's a flaky test:

=== RUN   TestPathCleanMallocs
    path_test.go:85: 
            Error Trace:    /home/runner/work/gin/gin/path_test.go:85
            Error:          Not equal: 
                            expected: float64(698)
                            actual  : int(0)
            Test:           TestPathCleanMallocs

And that the flaky test was a problem in the previous version, it was an issue back in Feb - https://github.com/gin-gonic/gin/pull/3502#issuecomment-1438175835 and it was introduced here https://github.com/gin-gonic/gin/pull/2596

The issue is coming from here:

https://github.com/gin-gonic/gin/blob/bdde009dbbbae890db4e6ffdd252e2b4e63a1b85/path_test.go#L84-L85

https://pkg.go.dev/testing#AllocsPerRun returns a float, but the https://pkg.go.dev/github.com/stretchr/testify/assert#EqualValues package takes an interface. There's a well known case that ARM float to int conversion is not the same as x86. Could be related to that, not sure, I'm just guessing.

Comment From: davidorozcog

Any progress on this? Any main issue to follow-up? Thanks

Comment From: a-h

The flaky test was (I think) set to be skipped in https://github.com/gin-gonic/gin/commit/fd60a24ab76c3c92955ba253c1f7eda9e4981c3c

I'm back here to this issue because of the new security issue with the protobuf dependency (https://github.com/gin-gonic/gin/commit/0d9dbbb44551a872d30fd89d4d55ba0515d646fd)

Users can work around this issue by executing a go get -u github.com/gin-gonic/gin@7a865dcf1dbe6ec52e074b1ddce830d278eb72cf to use the latest commit on the main branch, but...

Tagging a new release would allow Github Dependabot (and other tools that upgrade dependencies) to automatically suggest go.mod updates, automatically fixing security vulnerabilities in users's projects. I think that would close this issue.

@RedCrazyGhost, @ssfyn and @appleboy - I spotted that you've all recently committed. Is there a plan to tag a new release?

Comment From: appleboy

@a-h Yes. See the 1.10 milestone https://github.com/gin-gonic/gin/milestone/24 I will bump the new version recently.