This fallback already in place, see package docs:

Set the GOVULNDB environment variable to specify a different database, which must implement the specification at https://go.dev/security/vuln/database.

The distributed mechanism is to publish retractions.

Vulnerability reporting relies on somewhat centralized CVE IDs to allow communication between different parties, a fully decentralized option doesn't make sense here.

cc @golang/vulndb

As mentioned earlier, users can provide other vulnerability databases to govulncheck via GOVULNDB environment variable.

I wasn't clear, I think. I don't mean in the sense of GOPROXY=myproxy, I mean in the sense of GOPROXY=direct. Basically, have a way for module authors to declare vulns in modules themselves, identified by commit hash or version, e.g.

module example.com/foo

go 1.19

vulnerability {
  versions: v1.2.0...v1.2.9, v1.2.11
  description: "My description"
  method: Bar.Baz
}

Common identifiers can be derived from the module and vulnerability info, e.g. the example.com/foo:Bar.Baz:v1.2.0...v1.2.9,v1.2.11 vulnerability. Or maybe there's a naming convention like

module example.com/foo

go 1.19

vulnerability 2022-09-09 {
  versions: v1.2.0...v1.2.9, v1.2.11
  description: "My description"
  method: Bar.Baz
}

Vulnerability example.com/foo:2022-09-09.

That was what eventually became the retract directive: #24031

I believe this would need to go through a formal proposal process with pros, cons, motivation, etc.

That was what eventually became the retract directive

Thanks for pointing me to that.

• It looks like the retract directive is ignored by Go 1.15 and earlier:

  Go 1.15 and lower will report an error if a retract directive is written in the main module’s go.mod file and will ignore retract directives in go.mod files of dependencies.

  Wouldn't that be an issue when using the vuln tool for those Go versions?

• Retractions don't seem to be necessarily considered a security concern by the vuln tool/database, and aren't considered unless you upgrade the package manually or by Minimum Version Selection to a version that has the retraction

• Retractions don't flag particular functions/methods, as the vuln tool/database does

I believe this would need to go through a formal proposal process with pros, cons, motivation, etc.

If this is true, then we should fix the Go blog post to not point users to make vuln suggestions here by creating an x/vuln: issue. This isn't meant to be a suggestion in the formal Go proposal process sense.

If this is true, then we should fix the Go blog post to not point users to make vuln suggestions here by creating an x/vuln: issue. This isn't meant to be a suggestion in the formal Go proposal process sense.

I should have been more precise. My mention of the formal proposal process was in response to the suggested change

module example.com/foo

go 1.19

vulnerability 2022-09-09 {
  versions: v1.2.0...v1.2.9, v1.2.11
  description: "My description"
  method: Bar.Baz
}

which would also require modifications to the specification and handling of go.mod files. However, we can choose a different way to implement this.

My concern is that this would add an extra maintenance burden on the programmers so this would ultimately not be able to completely replace the existing approach. Or maybe it is not supposed to?

My concern is that this would add an extra maintenance burden on the programmers

I think this would actually be simpler for module owners. Instead of figuring out how to report a CVE, a GHABCDEFwhateverthisis, submit a report to the official Go vuln database, etc. etc., they can simply report the problem in go.mod, and the toolchain automatically surfaces the problem when others try to build with it. All the info is contained within the module itself, and published as one unit.

I guess the go tool would have to consult the latest version for vuln retractions regardless of what the minimum version selected for builds is.

so this would ultimately not be able to completely replace the existing approach

Which approach do you mean? The new vuln stuff?

My concern is that this would add an extra maintenance burden on the programmers

I think this would actually be simpler for module owners. Instead of figuring out how to report a CVE, a GHABCDEFwhateverthisis, submit a report to the official Go vuln database, etc. etc., they can simply report the problem in go.mod, and the toolchain automatically surfaces the problem when others try to build with it. All the info is contained within the module itself, and published as one unit.

I guess the go tool would have to consult the latest version for vuln retractions regardless of what the minimum version selected for builds is.

so this would ultimately not be able to completely replace the existing approach

Which approach do you mean? The new vuln stuff?

Yes, the current approach with a vulnerability database.

@tatianab @jba @neild

I would say that a decentralized approach would be a good basis, but you'd also want users to be able to specify a database they trust (defaulting to the Go Team's) for issuing vuln retractions on behalf of module owners, like if module owners are too slow to do it.

Perhaps if vuln retractions are cached in go.sum or something comparable to prevent bad actors from undoing module-based retractions, then database entries could be removed as the corresponding modules publish retractions. This keeps the "active" database size to a minimum, and keeps the vuln retraction history with the (cached) modules.