Repository navigation
Remove third party test dependencies #297
Description
The github.com/gin-gonic/gin dependency has a http response splitting vulnerability in versions less than 1.7.0:
gin-gonic/gin#2632
Upgrading the dependency to 1.7.0 or higher will fix this vulnerability (current version is 1.7.1)
Activity
nhooyr commentedon Aug 6, 2021
Hi @yinzara we don't actually use gin anywhere other than in tests but I'll be sure to do this in the next release.
nhooyr commentedon Aug 6, 2021
And apologies for the delayed response.
[-]HTTP Response Splitting Vulnerability - github.com/gin-gonic/gin[/-][+]Upgrade gin in the next release[/+]jmichalak-fluxninja commentedon Sep 29, 2021
@nhooyr Any update on this? Github alerts me with GHSA-h395-qcrw-5vmq
nhooyr commentedon Mar 6, 2023
Soon, my plan is to just move the third party tests to a different module. See #318 (comment)
[-]Upgrade gin in the next release[/-][+]Remove third party test dependencies[/+]Roman-Bober commentedon Jul 5, 2023
Any updates on removing gin dependency soon ?, Blackduck scanner fail on this with high security error.
prochac commentedon Aug 8, 2023
It seems that it shouldn't be necessary.
https://gophers.slack.com/archives/C9BMAAFFB/p1691163449401899
We plan to release SQL util and want to test it as many SQL drivers as possible. So I was worried about the dependencies from tests.
prochac commentedon Aug 8, 2023
For others, feel free to remove gin from your
indirectdependencies.emcfarlane/larking#78 (comment)
nhooyr commentedon Aug 18, 2023
@prochac can you copy and paste the contents of the link? I'm not a member of the Gophers Slack.
prochac commentedon Aug 18, 2023
Tomáš Procházka
14 days ago (<- relative to today's day: 2023-08-18, this was posted on 2023-08-04)
Hi, how do you deal with test dependencies?
What I strugle with is that if I test my module of SQL library then I want to check compatibility with many possible SQL drivers.
That means a lot of indirect dependencies for people just using the code, not test.
Example from wild, the websocket package recomended as replacement for golang.org/x/net/websocket
#318
I was thinking of separate integration test module, that would "hide" the heavy test dependencies.
Any other recomendation/practise? (edited)
Bryan C. Mills
11 days ago
This is one of the motivating use-cases for module graph pruning, added in Go 1.17.
Bryan C. Mills
11 days ago
Even though your test dependencies do appear in the module graph for your users, they should have relatively little impact — your users will only need to download the module contents (or even the go.mod files) for the dependencies of the packages they actually import.
Bryan C. Mills
11 days ago
So I suggest putting the integration tests in a separate package in the same module. Your users won't import that package, so they won't download its dependencies, but it will still be tested against the same dependency versions as the user-facing packages — with no version skew like you might otherwise have in a separate test-only module.
Tomáš Procházka
10 days ago
Thanks for your reply. I would accept that, but what about people? Somehow the less deps the better is considered by the Go comunity.
#297
Here it seems that they angry with CVE report of test-only dependency.
Could be said, that it's false positive?
Here are people changing library because of indirect dependency, regardless it's indirect/test-only 😕
emcfarlane/larking#75 (edited)
Tomáš Procházka
10 days ago
I simulated the problem, and you right. It shouldn't matter:
Only go.sum is bloated, but that shouldn't really matter
https://github.com/prochac/huge-test-deps
https://github.com/prochac/user-of-huge-test-deps (edited)
Jason Lui
9 days ago
oh, so if integration tests are in a separate package, it wouldn’t show up in this module’s go.mod?
Bryan C. Mills
9 days ago
More than that, even: if the integration tests are in a separate package, its test dependencies shouldn't even show up in the consumer's go.sum.
Jason Lui
9 days ago
oh it still shows up in this module’s go.mod, but not in its users’ go.mod, hmm
Bryan C. Mills
9 days ago
Right. Your go.mod file lists your own dependencies, including test dependencies, but module graph pruning limits the impact of your dependencies if they are not relevant to your consumers.
Jason Lui
9 days ago
there’s concerns from users though, like what
@prochac
said, if I see a module with a lot of dependency in go.mod I’d rather not use it :thinking_face:
question: if I separate those dependencies in a separate require block and comment them manually, would that grouping and comment be preserved by go tools?
Bryan C. Mills
9 days ago
In general yes, although the logic to preserve those blocks has been somewhat prone to bugs. 😅
Tomáš Procházka
8 days ago
@jason Lui
that's what I am planning to do too. Building an alibi for bloated go.mod 😄 (edited)
Bryan C. Mills
8 days ago
FWIW, you can always suggest that your users run go list -deps and/or go list -deps -test on the package(s) they're considering in order to report their actual dependencies.
Jason Lui
8 days ago
but it’s too much, people usually see a long go.mod and closes the page 😂
wspb: Remove
wspb: Remove
Remove third party dependencies from go.mod and go.sum
nhooyr commentedon Oct 13, 2023
Done in dev.