go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.01k stars 5.4k forks source link

Update or Replace dependencies that have not been updated for a long time (More than 2 years) #31700

Closed SomanathThilak closed 1 week ago

SomanathThilak commented 1 month ago

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:

  1. chartjs-adapter-dayjs-4
  2. mcaptcha
  3. dropzone
  4. escape-goat
  5. cache
  6. dingtalk_webhook
  7. levelqueue
  8. sshsig
  9. go-version
  10. go-ntlmssp
  11. blakesmith/ar
  12. chi-middleware/proxy
  13. reply
  14. buffer
  15. djherbis/nio
  16. compress
  17. rupture
  18. jsonld
  19. httpsig
  20. glob
  21. chardet
  22. go-gogs-client
  23. golang-lru
  24. html2text
  25. go-shellquote
  26. go-crypto
  27. pkg/errors
  28. otp
  29. cron
  30. goleveldb
  31. tstranex/u2f
  32. goldmark-highlighting
  33. goldmark-meta
  34. gomail.v2
  35. license-checker-webpack-plugin
  36. go-libravatar
  37. throttle-debounce
  38. tributejs
  39. uint8-to-base64
  40. vanilla-colorful
  41. vue-bar-graph

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

lunny commented 1 month ago

I wouldn't say it's a bug but this is obviously important.

wxiaoguang commented 1 month ago

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:

lafriks commented 1 month ago

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

techknowlogick commented 1 month ago

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?

GiteaBot commented 1 week ago

We close issues that need feedback from the author if there were no new comments for a month. :tea: