x/website/content/static/doc/modules: workflow documentation for managing transitive deps #44218
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:
The text was updated successfully, but these errors were encountered:
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
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)
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!)