`gorilla/mux` is archived about common

[bboreham]

My personal inclination is to do that after it becomes necessary. There were no changes in gorilla for years, so presumably it works fine.

[tspearconquest]

Unfortunately, "waiting until it becomes necessary" is not an option for organizations with security requirements. My org wants to adopt FluxCD, but we cannot do so if gorilla is used, because of the risk of an unknown CVE.

Since the Gorilla project is archived, issues cannot be opened against it. Therefore if a security researcher wanted to report a CVE finding, it would not be possible. Various open source vulnerability scanners like Trivy use GHSA to report on CVEs, and GHSA generates vulnerable/fixed versions from issues on the projects themselves.

This could lead to unknown CVEs being present in gorilla which nobody will ever know about.

Please consider this a formal request from a potential customer to replace gorilla.

[bboreham]

Can you point me at the non-archived Flux repo that depends on this repo?

[tspearconquest]

Hi, apologies, I don't know that there is one. I was more making the point that IF Flux uses gorilla... Then this would prevent our adoption of it. :)

we cannot do so if gorilla is used

Added emphasis to the quote

[bboreham]

Looks like the upstream position has changed, so I will close this issue.
gorilla/mux#707 (comment)
https://www.reddit.com/r/golang/comments/14xyido/the_gorilla_web_toolkit_project_is_being_revived/

Also, I looked into "if a security researcher wanted to report a CVE finding, it would not be possible", and found several avenues that could be used, e.g. https://github.com/golang/vulndb/issues/new. So this is not a concern.