x/website: workflow documentation for managing transitive deps

[novas0x2a]

@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!

[stevetraut]

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]

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]

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.

[novas0x2a]

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!)