mirror of
https://github.com/FiloSottile/mkcert.git
synced 2026-04-25 05:26:03 +03:00
[GH-ISSUE #546] CVE issues in go stdlib of mkcert #323
Labels
No labels
TLS stack issue
Windows
bug
duplicate
duplicate
enhancement
help wanted
help wanted
pull-request
question
question
root store
waiting for info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mkcert#323
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @djMax on GitHub (Aug 2, 2023).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/546
Environment
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:
and a couple more
@cyrusbehr commented on GitHub (Nov 7, 2023):
Same issue. Any updates on this?
@FiloSottile commented on GitHub (Apr 6, 2024):
None of those affect mkcert. mkcert doesn't even use those packages.
@djMax commented on GitHub (Apr 6, 2024):
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.
@FiloSottile commented on GitHub (Apr 6, 2024):
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.
@djMax commented on GitHub (Apr 6, 2024):
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?
@FiloSottile commented on GitHub (Apr 6, 2024):
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
@djMax commented on GitHub (Apr 6, 2024):
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.
@FiloSottile commented on GitHub (Apr 6, 2024):
I agree. I just think the issue is best fixed in 5-10 tools, rather than in 50-100k projects.
@djMax commented on GitHub (Apr 6, 2024):
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.