FiloSottile
CVE issues in go stdlib of mkcert
Environment
- Ubuntu 22.04
- 1.4.4
What you did
RUN sudo -E wget https://github.com/FiloSottile/mkcert/releases/download/v1.4.4/mkcert-v1.4.4-linux-amd64
&& sudo -E mv mkcert-v1.4.4-linux-amd64 mkcert
&& sudo -E chmod +x mkcert
&& sudo -E cp mkcert /usr/local/bin/
What went wrong
Seems this binary uses Go stdlib 1.18, and that has a number of CVEs that are fixed in 1.19.8:
- CVE-2023-24538
- CVE-2023-29402
- CVE-2023-24540
and a couple more
Yes, but if you're using that version of the stdlib, the automated tools that highlight container vulnerabilities will fire because of mkcert. It would be very helpful if you updated the tool to avoid this issue.
I don't think using automated tools that fail to do even package-level scoping and then pushing the churn onto every upstream project to reduce noise is sustainable.
My responsibility is making sure mkcert is not affected by security vulnerabilities. The responsibility of your tools is making sure they don't disturb you with false positives.
Because what could possibly go wrong with a tool intended to manipulate the core trust infrastructure of a system that doesn't bother to use up to date libraries?
There is real risk in updating, too, and an updates policy is a more nuanced topic than "bothering to use up to date libraries". I assure you I am very aware of every vulnerability in the Go project.
Also, https://filippo.io/maintenance#conduct
I'm not arguing that you "owe it to people" or that it's trivial to do, but I think closing the issue with no discussion and saying the tools in wide use in the largest cloud providers in the world are "not sustainable" asserts a position in the ecosystem that is a bit detached from reality. Even the noise created by these detected vulnerabilities has an effect on the overall security of people using it, as it can reduce the contrast for real issues. I think it's loud and clear that it is not your concern, and for us certainly we will just move on to other options. I appreciate the effort that made the original tool.
Even the noise created by these detected vulnerabilities has an effect on the overall security of people using it, as it can reduce the contrast for real issues.
I agree. I just think the issue is best fixed in 5-10 tools, rather than in 50-100k projects.
That seems like a very hard problem to try and diagnose whether, at runtime, a particular binary touches a particular part of the code. I'm not super familiar with go packaging, but I can see how that could generate a lot of false negatives.