Add go module support about jwt HOT 10 CLOSED

#3 adds module support. Thank you @sadmansakib

@lggomez @oxisto @Waterdrips Once this is merged we are more/less committed to a particular release cycle. Just want to get some 👀 to make sure we're on the same page

There are currently no tagged versions which effectively introduces golang-jwt/jwt as a v0. My suggestion would be to tag the module as /v1 once the security issue is addresses.

If done in a backwards-compatible way, golang-jwt/jwt v1 (module support) becomes a drop-in replacement for dgrijalva/jwt-go v3 (no module support)

From there we can continue improving the repo in a backwards-compatible way on the /v1 branch, or if necessary introduce a breaking /v2

from jwt.

@oxisto Great points

I would suggest first patching at least the one mentioned CVE about aud before releasing it as v1.0.0

Indeed we should patch that issue dgrijalva/jwt-go#428 before tagging a stable v1.

Ideally we can either cherry pick the existing fix (iirc this was addressed in the v4 preview branch) or copy/paste. This will keep parity between the repos.

I think its safe to remove the existing tags and keep this repo untagged for now as a v0. If the repo already got cached in the process we can request it be removed. https://go.dev/about/ > Removing a package

So, any objections to removing the existing versions and going with a v0 -> v1 approach (patched)?

from jwt.

Might need to be tested. I recall having to use a fork of another repo, but go mod refused to replace it because the replacement had a major version bump. It had to be retagged with a minor version bump to make go mod happy.

from jwt.

Lastly, I am not sure whether the original repo will get "transferred" or "archived" (see comment here), but if it gets transferred then this might change the outcome of how to proceed adding module support?

Thoughts, suggestions welcome.

So what I can gather from the comments on the migration thread, he is leaning towards archiving and making a manual reference to the new repo, rather than a transfer. So in this case we would be pretty much open do what we want in terms of release. So I guess the easiest for the user would be to start with a fresh v1.0.0. BUT I would suggest first patching at least the one mentioned CVE about aud before releasing it as v1.0.0

from jwt.

Update to this as I realised this after writing: If pkg.go.dev / godoc.org already knows about these existing releases on the new "namespace", we have a problem if we reach a v2/v3, etc. and re-release the same tags/releases that existed before. Not sure if we are already indexed by the go documentation site (probably).

from jwt.

How would this work with the replace directive? There are many libraries that are still using this https://github.com/dgrijalva/jwt-go, so, if possible, providing a mechanism for replace to work could be useful, at least for the foreseeable future.

from jwt.

How would this work with the replace directive? There are many libraries that are still using this https://github.com/dgrijalva/jwt-go, so, if possible, providing a mechanism for replace to work could be useful, at least for the foreseeable future.

Once there is a proper version and a go.mod file within the repo, the replace directive should work as expected, e.g.,

go mod edit -replace github.com/dgrijalva/jwt-go=github.com/golang-jwt/jwt@{semver}

// where semver could be a placeholder v0 or a patched v1

Alternatively, users can fetch the new module, search/replace the import paths, and then go mod tidy

Great point thought, we'll add a pinned issue or a README section for the various migration options.

from jwt.

@oxisto Great points

I would suggest first patching at least the one mentioned CVE about aud before releasing it as v1.0.0

Indeed we should patch that issue dgrijalva/jwt-go#428 before tagging a stable v1.

Ideally we can either cherry pick the existing fix (iirc this was addressed in the v4 preview branch) or copy/paste. This will keep parity between the repos.

I think its safe to remove the existing tags and keep this repo untagged for now as a v0. If the repo already got cached in the process we can request it be removed. https://go.dev/about/ > Removing a package

So, any objections to removing the existing versions and going with a v0 -> v1 approach (patched)?

We seem to be in luck, that https://pkg.go.dev/github.com/golang-jwt/jwt did not have it cached yet. It still shows the "request" button, which I dare not to click :) In any case, clicking it will probably fail because currently we still have to old module path. But good news after all, meaning that we will not run into conflicts with later releases.

from jwt.

Is it possible to publish a minor tag github.com/golang-jwt/[email protected] with CVE-2020-26160 fixed then later move to github.com/golang-jwt/jwt/v4/ for next major release??

from jwt.

Looks good, let's go for it.

from jwt.