Is this project still maintained?

[cep21]

Hi,

Thank you so much for this project. It's very helpful. I'm just wondering if there is still time to maintain this code. I noticed that https://github.com/auth0/go-jwt-middleware uses a fork due to "jwt-go not being actively maintained" and noticed a few tickets in https://github.com/dgrijalva/jwt-go/issues that mention security issues. An update on project status, or maybe finding someone willing to take over (maybe from the fork auth-0 uses?) would be useful.

Thanks!

[ripienaar]

It’s not maintained. There was some discussion earlier to make a org that maintains a fork maintained by multiple maintainers but it fizzled out, think people would rather score point by maintaining forks under their own banners alas.

[cep21]

I did some due diligence, and https://github.com/lestrrat-go/jwx seems like the current best JWT open source Golang library along the dimensions of

• Well maintained
• Go like API
• Code documentation, tests, and performance measurements.

[TimothyGu]

There is also https://pkg.go.dev/gopkg.in/square/go-jose.v2, which is also actively maintained and backed by a well-known company (@square).

[vibridi]

https://github.com/lestrrat-go/jwx seems a decent alternative but it exposes the Token as an interface, which is a significant difference from what this package did. Migrating old code comes with some overhead.
@ripienaar I might be interested in contributing without the need to "score points" with yet another fork.

[ripienaar]

@vibridi see discussion here #428 maybe try to ressurect that, if there's enough interest I can take another look at doing it.

[vibridi]

@ripienaar I read that discussion, the last point made by @lggomez makes critical sense:

because this one may be already audited and being used at companies following PCI DSS standards (just to name an example) and I'm not certain forks are freely allowed without a full re-audit

so if this is indeed a concern, the only solution is that @dgrijalva opens up this repo

Otherwise interested folks fork it and Dave still has to give his blessing with a readme update to point to the new "official" repo.
Dave's involvement is still sort of necessary because 1. there are already 800+ forks and who knows in what state all those are, and 2. today if you google golang jwt library the very first result is this repo, then some other repo with 200 stars and then an article from auth0 that mentions this repo. I would like to laugh but I just don't have it in me at this time.

About there being enough interest, I bet there is. The other two major alternatives are the Square lib, which is probably unmaintained itself, and lestrrat-go/jwx, which honestly has a weird API... I mean... the token is an interface and to set the standard claims you must call token.Set which returns an error...?

The only solution I see is a community effort, whose first accomplishment is to have @dgrijalva bequeath his code to them.

[ripienaar]

@vibridi anyone who is in such an environment are now well and truely screwed - because they are running vulnerable packages with no recourse as its unmaintained.

We'd be doing them a favour to trigger a re-audit imo.

We won't get a respose from @dgrijalva as you can see, he's completely radio silent on this project. Given that level of care moving to a new org is the right - if painful - thing to do.

[lggomez]

It sucks to be on this stage because we are at a moment with 2 complications at hand:

• This still is considered to be the canonical package by a lot of companies and resources (like the jwt site as I mentioned) and for practical purposes we can consider updating all of them with a fork notice as not feasible
• The owner is absent

In the past npm has dealt with similar issues by granting ownership to a new maintainer (or in this case a new organization should be needed with enough trusted new third party maintainers and preserving the original owner for the sake of honoring the repo's license). I don't know how github can intercede on cases like this, where intervention is clearly needed

[ripienaar]

GitHub cannot intercede it would be a massive trust issue if they got involved in something so inconsequential as a repo like this - or in fact any repo. I'd leave github immediately if they did something like hand over a repo to someone else without owner consent

This is not a new or unique problem, the only thing to do is make something new based on a fork - and learn from the mistakes ie. make a org and make sure enough interested parties are involved.

[Waterdrips]

@ripienaar Id be open to working on this in an org if there's some other interested parties.

I made the form3tech-oss fork to unblock us internally until some consensus was made in the community, never meant for it to be permanent 😆

The other approach is to "do nothing" and leave it up to people to adopt another lib. Both cases require a user to make changes to get a fix, so is it worth the commitment on maintaining yet another lib as there have been some suggestions in some of these threads as to alternatives.