Yaml3.0.0 vulnerability via objx v0.5.0 #1292

Activity

1. joaocbarbosa commented on Nov 4, 2022

   

   joaocbarbosa

   on Nov 4, 2022

   Last edited by joaocbarbosa

   More actions

   I'm wondering if we really can fix this problem without changing the objx library or breaking the circular dependency somehow.
   Even if we increase the testify version, pointing to a new objx tag (0.5.1 as example), the dependency tree will be like this:

   github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.2
   
   github.com/stretchr/testify@v1.8.1 github.com/stretchr/objx@v0.5.1
   
   github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.1
   
   github.com/stretchr/testify@v1.8.1 github.com/stretchr/objx@v0.5.0
   
   github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.0
   
   github.com/stretchr/testify@v1.8.0 github.com/stretchr/objx@v0.4.0
   
   github.com/stretchr/objx@v0.4.0 github.com/stretchr/testify@v1.7.1
   

   It will be inside this loop until the vulnerable version.
2. rohanthewiz commented on Nov 4, 2022

   

   rohanthewiz

   on Nov 4, 2022

   Author

   More actions

   I am seeing the same issue. Because of the circular dependency, updating one package will still leave a reference to respective dependency, and so we go down the stairs back to the older versions with the vulnerabilities.
   We would somehow have to update both at once...
3. brackendawson commented on Nov 4, 2022

   

   brackendawson

   on Nov 4, 2022

   Last edited by brackendawson

   Collaborator

   More actions

   The vulnerable gopkg.in/yaml.v3 v3.0.0 is not used:

   % go list -m all
   github.com/stretchr/testify
   github.com/davecgh/go-spew v1.1.1
   github.com/pmezard/go-difflib v1.0.0
   github.com/stretchr/objx v0.5.0
   gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
   gopkg.in/yaml.v3 v3.0.1

   go mod graph will still show it because it's still part of the graph used to resolve dependencies, and it will still appear in your go.sum so that Go can guarantee the integrity of that graph, but testify will not cause it to be compiled into your unit test or program binaries.
4. mgibson-r7 commented on Nov 11, 2022

   

   mgibson-r7

   on Nov 11, 2022

   More actions

   You might be able to solve this using an exclude in go.mod. So like in testify 1.8.2, have:

   exclude github.com/stretchr/testify 1.8.1

   Exact details may vary.
5. rohanthewiz commented on Nov 15, 2022

   

   rohanthewiz

   on Nov 15, 2022

   Author

   More actions

   Thank you @mgibson-r7. This absolutely solved the old dependencies issue!
   General note to clear up some of the above: any package's dependencies always forms a tree.
   Golang does purely source-level compilation, so I must gather the entire dependency tree before I can build.
   Features like exclude are a wonderful way of redirecting old references in an older package to newer versions.
   All of our Snyk dependencies are gone, except for one license issue.
   Thanks all!
6. rohanthewiz

   closed this as completedon Nov 15, 2022
7. westy92 commented on Mar 1, 2023

   

   westy92

   on Mar 1, 2023

   More actions

   Adding this to my go.mod worked for me:

   exclude github.com/stretchr/testify v1.7.1
   
8. dolmen

   added a commit that references this issue on Jul 4, 2023

   deps: fix dependency cycle with testify (stretchr#124)

   ...

   2fac82d
9. dolmen

   added a commit that references this issue on Aug 9, 2023

   deps: exclude old testify to break the dependency cycle from objx

   ...

   This issue will close once commit 838caea is merged into the 'master' branch.

   838caea
10. MovieStoreGuy

    added a commit that references this issue on Jan 21, 2024

    Merge pull request #1453 from stretchr/fix-1292-dep-cycle-with-objx

    ...

    12f05f7
11. algitbot

    added a commit that references this issue on May 6, 2024

    merge: deps: update module github.com/stretchr/testify to v1.9.0

    ...

    c2a9641