Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go Dependencies for JWX are not frequently updated #1146

Closed
akoserwal opened this issue Jul 3, 2024 · 9 comments
Closed

Go Dependencies for JWX are not frequently updated #1146

akoserwal opened this issue Jul 3, 2024 · 9 comments
Assignees

Comments

@akoserwal
Copy link

Following dependencies as needing to be updated frequently raises concerns around using JWX maintainability and security updates.

It makes strong case for using https://github.com/golang-jwt/jwt over lestrrat-go/jwx

  • github.com/lestrrat-go/httpcc [Last updated: 2 years ago]
  • github.com/lestrrat-go/httprc [[Last updated 5 months]
  • github.com/lestrrat-go/iter [Last updated: 2 years ago]
  • github.com/lestrrat-go/option [Last updated: 2 years ago]
  • github.com/lestrrat-go/blackmagic [Last updated: 2 years ago]
@lestrrat
Copy link
Collaborator

lestrrat commented Jul 3, 2024

I don't understand. They don't need updating because they are doing their jobs fine. What's your point?

@lestrrat
Copy link
Collaborator

lestrrat commented Jul 3, 2024

If anything, I would argue that the fact that do no need frequent updating means that they are more stable and therefore more secure.

@akoserwal
Copy link
Author

I agree with your point that "the fact that do not need frequent updating means that they are more stable" but

As an example:
https://github.com/lestrrat-go/blackmagic/blob/main/go.mod
use github.com/stretchr/testify v1.7.1

https://github.com/lestrrat-go/jwx/blob/develop/v2/go.mod
use github.com/stretchr/testify v1.9.0

I see the main library(jwx) dep version got updated, but the same package was used in Blackmagic, and the version wasn't updated. It's not a significant concern, but adding dependable can help keep the sub-package dependency updated.

@akoserwal
Copy link
Author

akoserwal commented Jul 3, 2024

The general rule followed to evaluate community projects is "when the project was last committed and which dependencies are used, when was the depedencies last updated"

@lestrrat
Copy link
Collaborator

lestrrat commented Jul 3, 2024

After 20+ years in FOSS I don't consider a test module dependency a reason enough to upgrade a module unless it introduces a critical side-effect, therefore I don't agree.
However, you are welcome to disagree and since you know so much how OSS works, I assume you know how to send a single line PR to the dependencies. Thank you in advance.

@lestrrat lestrrat closed this as completed Jul 3, 2024
@akoserwal
Copy link
Author

After 20+ years in FOSS I don't consider a test module dependency a reason to upgrade a module unless it introduces a critical side-effect, therefore I don't agree. However, you are welcome to disagree and since you know so much how OSS works, I assume you know how to send a single line PR to the dependencies. Thank you in advance.

That was just an example, not to point out the particular issue. Thank you for the discussion.

@lestrrat
Copy link
Collaborator

lestrrat commented Jul 3, 2024

Eh, pardon me? Then what did you want me to do?

@akoserwal
Copy link
Author

Eh, pardon me? Then what did you want me to do?

I am trying to propose the "lestrrat-go/[jwx" library as a solution instead of using golang-jwt/jwt. Some concerns were raised about the maintenance of subdependency. As a general rule of thumb considered in common, "when was the last commit date on the project" for evaluation, but it's not true in every case." As you mentioned, the sub-packages are stable.

I was trying to find pointers to showcase "lestrrat-go/[jwx" offers better features and well-maintained project. Sorry I didn't explained

@lestrrat
Copy link
Collaborator

lestrrat commented Jul 3, 2024

Well, TBH I was extremely angry, probably the angriest I'd been this year until I read your comment above.

You do realize you started this discussion by stating jwx is inferior to golang-jwt because of a non-issue (i.e. dependencies were recently updated or not).

You completely missed telling me the following in the original report:

I was trying to find pointers to showcase "lestrrat-go/[jwx" offers better features and well-maintained project. Sorry I didn't explained

This changes my perspective completely.

My answer wouldn't have changed: I don't see a reason I should update any of those modules as of now. They have been stable, AFAIK bug-free -- mostly, and therefore I do believe your original assessment that this has any sort of negative impact on maintenance or security of this module simply based on most recent release dates is completely wrong.

But if you only had explained what you were trying to do, I at least would have been much nicer to you!!!
Sorry for being upset and handling this while being upset, but seriously, that initial report was not nice to me.

You don't need to answer to this message. In fact, I will lock it after this.
Thanks for considering jwx.

@lestrrat-go lestrrat-go locked as too heated and limited conversation to collaborators Jul 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants