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

New Issue

2025-11-02T10:38:43-06:00

GiteaMirror commented

2025-11-02 10:38:43 -06:00

Originally created by @SomanathThilak on GitHub (Jul 25, 2024).

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:

chartjs-adapter-dayjs-4
mcaptcha
dropzone
escape-goat
cache
dingtalk_webhook
levelqueue
sshsig
go-version
go-ntlmssp
blakesmith/ar
chi-middleware/proxy
reply
buffer
djherbis/nio
compress
rupture
jsonld
httpsig
glob
chardet
go-gogs-client
golang-lru
html2text
go-shellquote
go-crypto
pkg/errors
otp
cron
goleveldb
tstranex/u2f
goldmark-highlighting
goldmark-meta
gomail.v2
license-checker-webpack-plugin
go-libravatar
throttle-debounce
tributejs
uint8-to-base64
vanilla-colorful
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

Originally created by @SomanathThilak on GitHub (Jul 25, 2024). ### 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

GiteaMirror added the issue/needs-feedback issue/not-a-bug labels 2025-11-02 10:38:43 -06:00

GiteaMirror closed this issue

2025-11-02 10:38:43 -06:00

GiteaMirror commented

2025-11-02 10:38:44 -06:00

@lunny commented on GitHub (Jul 28, 2024):

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

@lunny commented on GitHub (Jul 28, 2024): I wouldn't say it's a bug but this is obviously important.

GiteaMirror commented

2025-11-02 10:38:45 -06:00

@wxiaoguang commented on GitHub (Jul 29, 2024):

I do not think it is practicable or reasonable to do it for "every" dependency.

Think about a case:

A source file/function/package named "foo" in Gitea's repo, it hasn't been updated more than 2 years
A dependency package name "bar" from vendors, it hasn't been updated more than 2 years

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:

The old one has problems.
The new one works well and is actively maintained.

So feel free to propose PRs.

Some real examples about doing such replacement:

@wxiaoguang commented on GitHub (Jul 29, 2024): I do not think it is practicable or reasonable to do it for "every" dependency. Think about a case: * A source file/function/package named "foo" in Gitea's repo, it hasn't been updated more than 2 years * A dependency package name "bar" from vendors, it hasn't been updated more than 2 years 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: * The old one has problems. * The new one works well and is actively maintained. So feel free to propose PRs. Some real examples about doing such replacement: * #17707 * #30592

GiteaMirror commented

2025-11-02 10:38:45 -06:00

@lafriks commented on GitHub (Jul 30, 2024):

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

@lafriks commented on GitHub (Jul 30, 2024): 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

GiteaMirror commented

2025-11-02 10:38:45 -06:00

@techknowlogick commented on GitHub (Jul 30, 2024):

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?

@techknowlogick commented on GitHub (Jul 30, 2024): 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?

GiteaMirror commented

2025-11-02 10:38:45 -06:00

@GiteaBot commented on GitHub (Aug 30, 2024):

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

@GiteaBot commented on GitHub (Aug 30, 2024): We close issues that need feedback from the author if there were no new comments for a month. :tea:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13329