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
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:
go.sum. Same results as above.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.
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.v2module doesn't provide any relevant packages, so explicit upgrades to it are not maintained bygo mod tidy. If the main module is modified to usegopkg.in/yaml.v2, then the explicit upgrade to v2.3.0 is preserved after runninggo 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.