- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
You must log in or register to comment.
Well done. That dev doesn’t have to put up with that shit. People still treat opensource devs like free labor, pressuring them as if they are entitled to a product. If an opensource project is important to you or your company, contribute in some way that doesn’t pressure the dev, otherwise stfu.
My main issue with CVEs nowadays is that it seems one gets generated even when 99% of the use cases for the software in question are not vulnerable as the vulnerability requires a very specific configuration/circumstances/etc. to be exploitable. In large projects with lots of dependencies this adds a lot of noice and there’s a risk that actual important CVEs go unnoticed.
We get some concerned folks asking about vulnerabilities on our software all the time because some dependency has a critical vulnerability and that gets our stuff flagged as having critical vulnerabilities too, even tho you need to opt-in to that dependency in compile time and even when it’s present it can only be abused by users with enough privilege to do directly much more than anything the vulnerability can end up doing.
The CVE has to do with the utility not correctly identifying private IP addresses supplied to it in a non-standard format, such as hexadecimal. This would cause the ‘node-ip’ utility to treat a private IP address (in hex format) such as " 0x7F.1…" (which represents 127.1…) as public.
This is a ridiculous expectation. Providing addresses in an unsupported format doesn’t yield correct results? Who wouldda thunk it. Clean up your fucking code and pass it in as expected, or make your own damn node-ip.
Recurring incidents like these raise the question, how does one strike a balance?
Relentlessly reporting theoretical vulnerabilities can leave open-source developers, many of who are volunteers, exhausted from triaging noise.
On the flip side, would it be ethical if security practitioners, including novices, sat on what they thought was a security flaw—so as not to inconvenience the project maintainers?
This was already answered in the article: verify your security findings. Make a POC that actually exploits the vulnerability, then submit it with your report.
