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

x/website/content/static/doc/modules: workflow documentation for managing transitive deps #44218

Open
novas0x2a opened this issue Feb 11, 2021 · 4 comments

Comments

@novas0x2a
Copy link

@novas0x2a novas0x2a commented Feb 11, 2021

@stevetraut, @bcmills said I should ping you on this :)

The new workflow doc is great, but I had suggestions for workflows to support/document that aren't currently directly covered by any existing docs. The high level questions are:

  • How do I unequivocally, permanently exclude a vulnerable version of a module (and all prior versions) from my transitive set, (probably due to a CVE), when the upstream has released a fixed version?
  • What is the supported method of generating a complete transitive set of deps, for the purposes of feeding scanning tools that expect to see that? NexusIQ documents a method (the go.list path) but it's not clear that's an intended workflow.

Thanks!

@novas0x2a novas0x2a changed the title docs: workflow documentation for excluding deps from the transitive tree docs: workflow documentation for managing transitive deps Feb 11, 2021
@stevetraut
Copy link

@stevetraut stevetraut commented Feb 11, 2021

Hey @novas0x2a, I can add content covering those questions once I know the answers myself. We can decide where those answers belong once we have them in hand.

@bcmills Can you add something in a comment here about those?

@stevetraut
Copy link

@stevetraut stevetraut commented Feb 11, 2021

By the way, @novas0x2a, will you say something about the use case the new content you're requesting is intended to support? What are you wanting to accomplish that the content would help you with?

@danp
Copy link
Contributor

@danp danp commented Feb 11, 2021

I'll let @novas0x2a recap but if it helps this did come out of a discussion in the modules channel of the Gophers slack starting here.

@dmitshur dmitshur changed the title docs: workflow documentation for managing transitive deps x/website/content/static/doc/modules: workflow documentation for managing transitive deps Feb 11, 2021
@gopherbot gopherbot added this to the Unreleased milestone Feb 11, 2021
@novas0x2a
Copy link
Author

@novas0x2a novas0x2a commented Feb 12, 2021

The thing that spawned the question was basically what I said in the description, blocking out specific cve-vulnerable version ranges of packages. At the time, I had about 6 replace statements in my go.mod, overriding vulnerable version selections (it wasn't clear to me at the time that there was any other way). The replace statements, of course, prevented later upgrades on those packages from happening, unless I did I manually. I went through several other permutations (adding hundreds of exclude statements, of all past vulnerable versions, and a few others).

Bryan set me right, by telling me what the intended workflow is, but the main problem is the intended workflow currently seems like an accidental side effect of how gomod / mvs works instead of intended behavior. Documenting it as intentional behavior would alleviate that concern!

The go.list-related item seems like the current best way to list all of the packages/versions that actually ended up in the final transitive dep set (for those of us that need to know for sure what was chosen, for scanning purposes). However, I know that the definition of all has changed in the past, so I was hoping to get a workflow doc section on what the most-correct way is to get that final resolved set is (whether it's the method shown here, or some other method)

Listing / tracking the final dep set is our defense against a series of events that reintroduces a vulnerable package, for example (if i understand this correctly)

  1. i add a requires directive to force a (transitive dep) package to upgrade (which is then annotated as // indirect)
  2. my direct dep which depends on said indirect dep bumps their dep, so when i bump my dep, tidy will drop the indirect dep (since it's no longer required)
  3. My direct dep reverts their bump, or drops that dep completely, or something like that which causes my indirect require line to be necessary again.

If this series of unfortunate events happens, I'll have an opportunity to catch it, both by eye (we check the go.list into the repo, so it will be in the PR) or due to the security scan noticing.

Thanks! (And sorry for the wall of text!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants