Unmaintained Libraries

[snyff]

I reviewed the libraries listed on jwt.io to check the date of their latest commits:

Would it make sense to remove libraries that haven't been updated in several years?

Additionally, the following libraries are now archived:

• https://github.com/zolamk/jwt has been archived on Mar 27, 2018.
• https://github.com/olehlong/jwtd has been archived on Oct 8, 2021.
• https://github.com/square/go-jose has been archived on Feb 27, 2023.
• https://github.com/nov/jose-php has been archived on Jan 3, 2024.
• https://github.com/robbert229/jwt has been archived on Apr 22, 2024.
• https://github.com/babelouest/rhonabwy has been archived on Nov 11, 2024.

Should these be removed, or would it be better to add a warning to indicate their archived status?

I already submitted a PR for zolamk/jwt to remove it from the list as it is both archived since 2018 and the code hasn't been touched in 7 years.

[DanOnCall]

Howdy, thanks for sharing this report. We are currently working on the v2 of the site and one of the key areas I am discussing internally is on developing a strategy for the JWT library directory management. If I may ask you, what do you think are good measures to take?

I like what socket.dev is doing on flagging unmaintained code as a risk, so we could go the path where we put a red flag on the library to caution about it's status.

Btw, what did you use to generate the pie chart? That is super cool and helpful 🙏

[snyff]

Hi Dan,

Thanks for the quick reply! I’ve noticed that some of the projects listed on jwt.io/libraries are outdated, and others seem to have been submitted by people who never fully completed their work. I believe there should be a minimum standard, particularly in terms of algorithm support. For instance, some libraries have hardcoded algorithms or don’t even fully comply with the JWT format (e.g., using a string instead of a Unix timestamp for expiry).

The only drawback to tightening the criteria is that it may become harder to add new libraries—but that’s not necessarily a bad thing.

Here’s what I dislike about the current list:

• There doesn’t seem to be a clear order.
• Some libraries haven’t been updated in a long time.
• Some libraries lack adequate support. For example, I reported this issue a while back, and I’m still waiting for an update.

This makes it challenging for developers to choose a library, as there’s often a huge gap in maturity between two libraries listed side by side.

To address this, we could consider the following criteria to remove libraries or add warnings:

• The year of the latest commit.
• Whether the project is archived.
• The OpenSSF Scorecard rating (https://scorecard.dev/).

I’m happy to send a PR to remove projects older than 20?? and any archived ones if you’d like. Just let me know!

I used a script in Ruby and Apple Keynote to generate the pie chart.

Best regards,

[DanOnCall]

Thanks for your prompt reply as well, Louis 🙏

I appreciate your offer and, if you have the time, that PR could help us with the direction of the v2 version and how I can also communicate this need to my internal teammates.

I think that if you want to expand on the current JSON model to add a flags property that could work well. You can add other properties within flags to reflect the security profile you presented above. I could share that report internally for us to see the gaps and imbalances and how we could report this information in the UI.

Do you think getting a report from tools like Snyk or Socket.dev would help too? The challenge is that some libraries are on languages that are not supported by these scanning tools.

But nonetheless, any quality data that we can show to help people make an informed decision on the library to use is a good direction. Thanks for your time and attention on this, it's very impactful.

[snyff]

See #718 I added the details in the library section. Happy to move them as flags if it's easier.

[snyff]

Ideally we could also add some of those recommendations as flags: How to Securely Design Your JWT Library

[DanOnCall]

@snyff thanks so much for this contribution. Apologies for the delayed response I was out-of-office last week.

Thanks for sharing that resource as well on the recommendations. I'll be discussing next steps for the libraries page in the next weeks internally 🙏

Btw, semi-tangential question: Do you think that it's critical for the debugger site / UI itself to remain open source? The reason I ask is because I have thought about putting it in a monorepo that would make maintenance easier but it's closed source. Thanks for your insight on this matter :)

[snyff]

@DanOnCall I think it mostly depends on the number of contributions you are getting. People will get access to the JS, CSS, HTML anyway...