Closed SomanathThilak closed 1 week ago
I wouldn't say it's a bug but this is obviously important.
I do not think it is practicable or reasonable to do it for "every" dependency.
Think about a case:
What's the fundamental difference? Should every package in Gitea also be rewritten regularly to make them "updated in every 2 years"?
These dependencies also appear to lack active ongoing development.
A package doesn't have active ongoing development doesn't mean it can't do its work. If it works well, then no hurry to take any action.
Our concern is that .... they may be susceptible to newer security vulnerabilities. Additionally, support could be an issue if any problems arise, due to the lack of active development.
Think about the case above: does it also mean that "a source file/function which hasn't been updated more than 2 years in Gitea" is also "susceptible to newer security vulnerabilities? I do not think so.
If any security vulnerability is found in any package, we could fix it in first time equally. Actually, a long-time-used old package sometimes also implies "it is stable enough", if no security vulnerability is found in it but we just replace it with a newer one, the newer one might have new problems or new security vulnerabilities.
And If "support could be an issue", there are many methods to make it better, including: find an alternative, fork it and maintain, re-implement in Gitea as an internal package. But I do not think it's worth to take any early action before "support becomes an issue".
Considering this please let us know if there are any plans to update/replace those with newer dependencies.
I mean that it is not practicable or reasonable do it for "every" dependency (we shouldn't just list them and say "hey please replace every dependency")
Actually quite welcome to propose PRs to update legacy dependencies if:
So feel free to propose PRs.
Some real examples about doing such replacement:
How vue-bar-graph is not updated and/or maintained? For quite some time it was not updated as there was no need to do it, as soon as the problem was found it was fixed and a new version was released. There is really no point in changing dependencies if there are no problems with them. IMHO this issue does not give any meaningful information on why dependency should be replaced so I would say it should be closed
Thanks for opening this ticket and starting this discussion. We do regularly update deps, but some of them have also dropped off, or just don't need updates. There are also some such as gomail where there is a discussion on what to do with it, as there aren't going to be updates to it and there are some real world examples of functionality that users require to use with various different providers.
I think next steps could be to go through each of the deps listed and determine what needs to be done (switch to a new one, keep as is, or something else). As each of them require specific context to analyze an open-ended issue may have some things be lost if we discuss all of them in a single thread, so if some one needs extra discussion, a new issue could be opened for it. Thoughts?
We close issues that need feedback from the author if there were no new comments for a month. :tea:
Description
Hi Team,
We noticed quite a few dependencies used for gitea have not been updated for a long time . These dependencies also appear to lack active ongoing development.
Our concern is that, given the age of these dependencies, they may be susceptible to newer security vulnerabilities. Additionally, support could be an issue if any problems arise, due to the lack of active development.
Considering this please let us know if there are any plans to update/replace those with newer dependencies.
Below is a list of dependencies that were last updated approximately 2 years ago:
Gitea Version
1.22.1
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Gitea built using the dockerfile and running as a container.
Database
None