Comments (10)
#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.
Related Issues (20)
- SigningString produces a string without a signature HOT 2
- RSA-PSS (RSASSA-PSS) keys are unusable in Go language
- Let KeyFunc take Context as parameter HOT 3
- Customize the unit of timestamp/exp in payload HOT 1
- ECDSA signature is invalid
- I found an error message "token has invalid claims: token is expired"
- Only some registered claims can be optionally required HOT 1
- I have no RegisteredClaims. I have error key is invalid HOT 4
- Question / FR: Subsequent Verification of an Unverified Token
- Consider validating key length HOT 5
- 希望可以校验token格式 I hope that the token format can be verified HOT 3
- token signature is invalid: signature is invalid HOT 11
- Still trying to understand 'ParseRSAPublicKeyFromPEM' HOT 11
- Documentation around Parse()
- Is it possible to just parse a JWT without verifying its signature? HOT 2
- Permit only certain errors on parsing
- Version v5 not found HOT 3
- which golang-jwt/jwt version can be used when building with golang1.13.8 HOT 1
- Add option to change time precision for creation/parsing tokens. HOT 5
- bug(token): Interface includes constraint elements, can only be used in type parameters HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jwt.