Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

golang.org/x/net < 0.17.0 security vulnerability #3755

Closed
zacharyarnaise opened this issue Oct 12, 2023 · 7 comments
Closed

golang.org/x/net < 0.17.0 security vulnerability #3755

zacharyarnaise opened this issue Oct 12, 2023 · 7 comments
Milestone

Comments

@zacharyarnaise
Copy link

Just a heads up to inform you that prior to version 0.17.0, golang.org/x/net is subject to the following vulnerability:

Looks like the pull request has already been made: #3754
Any maintainer could look into this please? 🙏

Thanks!

@vyrwu
Copy link

vyrwu commented Oct 18, 2023

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.

@mwillfox
Copy link

mwillfox commented Nov 1, 2023

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

@kwenzh
Copy link

kwenzh commented Nov 16, 2023

the same trouble

@a-h
Copy link

a-h commented Nov 16, 2023

The security fix was merged in #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 - #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 - #3502 (comment) and it was introduced here #2596

The issue is coming from here:

gin/path_test.go

Lines 84 to 85 in bdde009

allocs := testing.AllocsPerRun(100, func() { cleanPath(test.result) })
assert.EqualValues(t, allocs, 0)

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.

@davidorozcog
Copy link

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

@a-h
Copy link

a-h commented Mar 23, 2024

The flaky test was (I think) set to be skipped in fd60a24

I'm back here to this issue because of the new security issue with the protobuf dependency (0d9dbbb)

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?

@appleboy
Copy link
Member

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

@appleboy appleboy added this to the v1.10 milestone Mar 23, 2024
@appleboy appleboy closed this as completed Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants