please release a new version of the api module to make vulnerability scanners happy

[eli-darkly]

This issue is a replacement for #10597. When I filed that one, I had some misunderstandings that muddied the waters; the underlying problem is described better here.

Briefly: we've become aware that at least one vulnerability scanning tool (Black Duck)—and/or whatever vulnerability database it is using, which other similar products may also be using—identifies vulnerable versions of Consul very generally as being vulnerable versions of any Go module in this repo with a matching version tag. For instance, https://nvd.nist.gov/vuln/detail/CVE-2019-12291 describes a vulnerability in "Hashicorp Consul 1.4.0 and 1.5.0". It is clearly referring to the Consul agent, not the API client; the vulnerability as described is a server-side issue. Nevertheless, if my software uses v1.5.0 of github.com/hashicorp/consul/api, the scanner regards that dependency as being simply "Consul v1.5.0" and flags this as unacceptable.

For this and several other CVEs (see below), it is not possible to work around this problem by updating to a newer version of the api module that happens to match a fixed version of the root module (an update that wouldn't be fixing an actual vulnerability, but would nevertheless satisfy the scanner)... because no such version exists. For obvious reasons the api module is released much less frequently than the main product, and it hasn't had a release since these CVEs were fixed, so the minimum acceptable versions of "Consul" per the CVE are higher than the last patch of api.

This isn't exactly your problem, but it is a real problem. We can only get so far by telling our customers "these are not real vulnerabilities", and we can't count on the makers of these scanning products to make their logic more sophisticated. So unless there's some other workaround I've missed, the only options are 1. we switch to using a fork of this repo (doable, but a semi-breaking change and bad for maintainability) or 2. you release a version of api with no code changes, just to catch its versioning up to the root module. I hope you'll either consider this or let me know if there's another option.

The CVEs we're being flagged on are http://nvd.nist.gov/vuln/detail/CVE-2019-12291, http://nvd.nist.gov/vuln/detail/CVE-2020-7219, http://nvd.nist.gov/vuln/detail/CVE-2020-13250, http://nvd.nist.gov/vuln/detail/CVE-2020-13170, http://nvd.nist.gov/vuln/detail/CVE-2020-7955, http://nvd.nist.gov/vuln/detail/CVE-2020-12797, http://nvd.nist.gov/vuln/detail/CVE-2020-25864, and http://nvd.nist.gov/vuln/detail/CVE-2020-28053.

[mikemorris]

updating to a newer version of the api module that happens to match a fixed version of the root module (an update that wouldn't be fixing an actual vulnerability, but would nevertheless satisfy the scanner)... because no such version exists

Have you tried updating to the latest 1.9.1 tag of the consul/api module, https://github.com/hashicorp/consul/releases/tag/api%2Fv1.9.1? We do try to ensure backwards compatibility with newer releases of the consul/api module, so that may be a short-term option.

I do empathize with this being a real problem, but unfortunately I don't think there's an easy fix here - ultimately, we'd prefer to see Go module detection handled properly in the Black Duck vulnerability scanner. I wouldn't suggest forking to add new tags, and we don't want to change the versioning scheme or publish superfluous releases (although they're currently at similar versions, the consul/api module versions do not strictly track Consul versions - it is versioned and can be released independently, and does follow SemVer conventions for breaking changes, while Consul itself does not, and may introduce breaking changes in "minor" version releases, (e.g. v1.5.0, v1.10.0 etc).

We have considered longer-term changes to work around this and other issues related to submodules, such as extracting the consul/api module into a separate hashicorp/consul-api repository, but that would be a more substantial effort and is not something we have plans to do yet.

[eli-darkly]

Have you tried updating to the latest 1.9.1 tag of the consul/api module

Unfortunately, 1.9.1 is still disallowed by https://nvd.nist.gov/vuln/detail/CVE-2020-25864. I mean, again, I realize that that CVE doesn't actually refer to v1.9.1 of api, but scanners that have this issue will flag v1.9.1 of api anyway. That's what I meant by saying that for some of these CVEs, "it is not possible to work around this problem by updating to a newer version of the api module that happens to match a fixed version of the root module ... because no such version exists".

ultimately, we'd prefer to see Go module detection handled properly in the Black Duck vulnerability scanner

I wholeheartedly agree. To be clear though, I would not assume that that's the only such product that has such an issue. It might be, it might not. If a product has the ability to read Go module dependencies from an executable, and if it has a database that identifies Go-based products by a module path, I think this would be a very easy mistake for them to make. To not make it would require them to replicate Go's build logic in ways that are not exactly self-explanatory.

[mikemorris]

FWIW we've published a new release of consul/api as part of our latest patch releases today, hope this helps.

[eli-darkly]

@mikemorris Thank you! I'll try it out ASAP.

[eli-darkly]

By the way, I did bring up this issue about the Go module behavior of Synopsis's Black Duck scanner in the Synopsis support forum, using Consul as an example although of course this could also affect other tools. It looks like at least one other team has had the same issue. Unfortunately, I don't know if there is a better way to get Synopsis's attention on this matter.

I'm hoping that switching to the 1.10 version of the api module will solve this specific problem for the moment. Of course (as I mentioned in the linked post) it's not a long-term solution because if there are ever any CVEs filed for v1.10.0 of the Consul server, it'll be the same problem again. But it's still very helpful to have a new release.

[eli-darkly]

There were in fact CVEs for v1.10.0, so that one didn't make a difference, but I see that v1.11.0 of the API now exists and there don't seem to be any CVEs for that version of the server, so that's good.