Plans to tag latest branch to include github.com/nats-io/nats-server/v2 v2.8.4?

[djo128]

FOSSA has identified nats-server v2.5.0 to have a high severity vulnerability:
https://nvd.nist.gov/vuln/detail/CVE-2022-24450

Your master branch is already using:
github.com/nats-io/nats-server/v2 v2.8.4

But your latest tag, v0.12.0, is using:
github.com/nats-io/nats-server/v2 v2.5.0

✋ Are there plans to release a new tag to include this version bump on nats-server?

[peterbourgon]

No. There's no reason for modules like Go kit to tag new releases for dependency updates, because the version of dependencies that are included in final binaries are controlled by the downstream consumers.

[ChrisHines]

You don't need a replace, just go get the version of nats-server you want. That will update the require directive in your go.mod which controls the version used in builds. The version in the go-kit go.mod is only a minimum and any dependent module can require a newer version whenever they want.

[ChrisHines]

Also, if your program doesn't use nats-server but does use go-kit I would not expect the nats-server module to be in your go.mod file if you have run go mod tidy. For example, here's a simple program that only uses the endpoint package and does nothing useful:

package main

import (
	"context"

	"github.com/go-kit/kit/endpoint"
)

func main() {
	endpoint.Nop(context.Background(), nil)
}

The go.mod file for the program looks like this:

module example/playground

go 1.20

require github.com/go-kit/kit v0.12.0

There is no sign of nats-server or any other module from the go-kit go.mod file.

[djo128]

Thank you for detailed response. Correct, we do not need nats-server in our program so go mod tidy will simply remove it anyways.

I think the problem is that FOSSA is flagging nats-server from the nested dependencies. go-kit is also a nested dependency we use and it is located a few layers deep.

The only way I was able to resolve this was by using replace, which is not recommended. If I just do go get, then go mod tidy will clean this up in our go.mod file.

[ChrisHines]

That sounds like a bug in FOSSA. Since Go 1.17 your go.mod file contains the full list of all module dependencies your module needs to build and run its tests. I don't see any reason why FOSSA would need to check for anything beyond your go.mod file. We made a concerted effort to update the Go kit go.mod file to play nice with the new semantics of Go 1.17 shortly after that change was made, but it doesn't make sense for us to be constantly tagging new releases for every new version of all of go-kit's dependencies if go-kit itself hasn't changed.

[djo128]

Gotcha, I really appreciate your input. I'll investigate more from my side next 👍