Go-github: go mod use latest version

Created on 15 Sep 2020  路  7Comments  路  Source: google/go-github

Is there a way to force the latest version for dependencies.

e.g. my go.mod looks a bit like this:

```go.mod
replace(
gopkg.in/yaml.v2 v2.0.0-20170812160011-eb3733d160e7 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.0.0 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.1.0 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.0 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.1 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.2 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.3 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.4 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.5 => gopkg.in/yaml.v2 v2.2.7
gopkg.in/yaml.v2 v2.2.6 => gopkg.in/yaml.v2 v2.2.7
)

can i do something like: 

```go.mod
replace (
    gopkg.in/yaml.v2 v2.x.x => gopkg.in/yaml.v2 v2.2.7
)

My usecase is to prevent security flaws such as a Billion Laughs Attack which is yaml.v2 is vulnerable to in

Most helpful comment

Thanks for providing details @gmlewis. I'm able to reproduce the behavior you're seeing.

My current understanding is that it's working as intended per https://golang.org/ref/mod#go-mod-tidy. The gopkg.in/yaml.v2 module doesn't provide any relevant packages, so explicit upgrades to it are not maintained by go mod tidy. If the main module is modified to use gopkg.in/yaml.v2, then the explicit upgrade to v2.3.0 is preserved after running go mod tidy.

I agree the behavior seems surprising in this situation where there's a reason to upgrade that module requirement due to a security concern in the otherwise selected v2.2.2 version, and it might be worth filing a cmd/go issue about it.

All 7 comments

According to:
https://jfrog.com/blog/shift-left-security-with-golang-in-vs-code/

you can add this to your go.mod:

require (
    gopkg.in/yaml.v2 v2.3.0
)

But I just tried it and couldn't get it to work, so please let us know if you find a working solution.
Thanks.

@gmlewis i tried also. It does not work.

But I just tried it and couldn't get it to work, so please let us know if you find a working solution.

@gmlewis In what way did it not work? A require directive should work to ensure the mentioned version (or a later version) is selected. Maybe you had a replace directive too? Those take higher precedence.

If this issue isn't related to go-github, then some of the places listed in http://golang.org/wiki/Questions may help you get better answers.

@dmitshur - I'm away from my machine until 9/30, and I don't remember the details now. When I return, I will try it out again and if it still fails, I'll share the details. Thanks for the confirmation.

I apologize for the delay, but now I have investigated this once again... this time with Go version 1.15.5.

I started with this test case:
https://github.com/gmlewis/go-github/tree/master/example/newreposecret
and added this line to go.mod:

diff --git a/example/newreposecret/go.mod b/example/newreposecret/go.mod
index 5d05d95..1fa359a 100644
--- a/example/newreposecret/go.mod
+++ b/example/newreposecret/go.mod
@@ -6,4 +6,5 @@ require (
        github.com/GoKillers/libsodium-go v0.0.0-20171022220152-dd733721c3cb
        github.com/google/go-github/v33 v33.0.0
        golang.org/x/oauth2 v0.0.0-20200902213428-5d25da1a8d43
+       gopkg.in/yaml.v2 v2.3.0
 )

With Go v1.15.5, running go test ./... works fine.

However, the moment I type go mod tidy, that line is removed from go.mod, reverting to the earlier version v2.2.2 found in go.sum! This was quite surprising, so I tried a couple of experiments:

  • I tried starting with the original go.sum. Same results as above.
  • I tried deleting the original go.sum. Same results as above.

So it seems that this will work _as long as you don't run go mod tidy_!

One other odd thing I noticed is that when explicitly specifying a specific version, the go.sum file always keeps the older version around (after running go test ./...).
I also found odd behavior when running go mod why gopkg.in/yaml.v2... I did not expect it to modify go.sum, but immediately after I run it, a new line was added to go.sum:

gopkg.in/yaml.v2 v2.3.0 h1:clyUAQHOM3G0M3f5vQj7LuJrETvjVot3Z5el9nffUtU=

in addition to the existing line:

gopkg.in/yaml.v2 v2.3.0/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=

So I'm still a bit confused as to the behavior of go mod, but it is probably just me.

I'll write a PR to update this example and then close this issue.

Thanks for providing details @gmlewis. I'm able to reproduce the behavior you're seeing.

My current understanding is that it's working as intended per https://golang.org/ref/mod#go-mod-tidy. The gopkg.in/yaml.v2 module doesn't provide any relevant packages, so explicit upgrades to it are not maintained by go mod tidy. If the main module is modified to use gopkg.in/yaml.v2, then the explicit upgrade to v2.3.0 is preserved after running go mod tidy.

I agree the behavior seems surprising in this situation where there's a reason to upgrade that module requirement due to a security concern in the otherwise selected v2.2.2 version, and it might be worth filing a cmd/go issue about it.

Was this page helpful?
0 / 5 - 0 ratings