Switch to github.com/golang-jwt/jwt

[vovinacci]

Closes #1026

This PR switches to github.com/golang-jwt/jwt to address security vulnerability. More details in the issue and GHSA-w73w-5m7g-f7qc

[peterbourgon]

@sagikazarmark Look good to you?

Just saw discussion here. Remind me the breaking change? Just that the types are different?

[sagikazarmark]

After taking a more thorough look at the implementation, I'm not sure that there is a breaking change, but I suspect there might be.

Basically, those different types referenced in the public API are all interfaces and I assume the new package didn't break those overnight, so in theory the replaced types could be backwards compatible with the old library.

In practice, though, some of the types used internally (eg. standard claims struct) are not interfaces, so those could break.

A simple test to check if there is a breaking change would be (temporarily) changing back the packages in tests to the old module to see if it works with the new code.

I'm not particularly worried about a breaking change (the library is basically abandoned after all), but if there is a breaking change, it should be released in a minor version, not a patch. Go 1.17 is just around the corner and Chris wants to cut a new release after that (hoping that we can further reduce the amount of dependency downloads).

[peterbourgon]

OK let's bench this until the next release.

[vovinacci]

@peterbourgon Do you have any preliminary release date in mind?

[AliLogic]

Any updates on this?

[sagikazarmark]

Can you please upgrade the library to v4?

[vovinacci]

@sagikazarmark Done

[shogo82148]

I recommend to upgrade to Go 1.17 pruned module graphs.

https://golang.org/doc/go1.17#go-command

go mod tidy -go=1.17

It enables some optimizations, such as Lazy module loading.

[eli-darkly]

@shogo82148 If that would require setting the minimum version to 1.17 in go.mod, I would very strongly prefer that they not make that change, at least not yet. Go 1.17 was just released and we can't all immediately update our projects to require it.

[sagikazarmark]

I recommend to upgrade to Go 1.17 pruned module graphs.

This is already in progress on another branch. Not sure which will be merged first yet.

[andig]

@shogo82148 If that would require setting the minimum version to 1.17 in go.mod, I would very strongly prefer that they not make that change, at least not yet. Go 1.17 was just released and we can't all immediately update our projects to require it.

Imho this does not raise the minimum version.

[eli-darkly]

@andig:

Imho this does not raise the minimum version.

Could you say more about why you think it wouldn't? My reading of the linked documentation is that pruned module graphs are only a thing in go.mod files that specify go 1.17.

[shogo82148]

pruned module graphs are just required directives.
So, Go 1.16 or earlier parses them as extra dependencies.
This has no negative effects, because these extra dependencies are also in go.sum and Go 1.16 loads whole dependencies in go.sum.

The go 1.17 directive enables new language features, and changes the go command behavior. https://golang.org/ref/mod#go-mod-file-go
However it doesn't break backward compatibility.

When Go 2.0 comes out in the future, Go 2.0 will not be able to import modules that contain the go 1.17 directive.