4 ms·
>[...] Incidentally, one of the Log4j maintainers’ GitHub sponsors profile is here, if you would like to contribute some money to his cause. [...] these compani
by jasode 5y ago
>[...] Incidentally, one of the Log4j maintainers’ GitHub sponsors profile is here, if you would like to contribute some money to his cause. [...] these companies should ponder which is more expensive: $100k/year salary for a maintainer of a project they are heavily dependent upon,
I don't understand the logic of cause & effect the author laid out.
Commercial software with well-paid programmer employees also have long lists of CVE/RCE including MS Windows, Azure, AWS, Adobe PDF reader, Oracle database, etc.
I think the crux of the author's argument is the 2nd paragraph:
>Like many projects, Log4j is only maintained by volunteers, and because of this, coordination of security response is naturally more difficult: a coordinated embargo is easy to coordinate, if you have a dedicated maintainer to do it. In the absence of a dedicated maintainer, you have chaos: as soon as a commit lands in git to fix a bug, the race is on: security maintainers are scurrying to reverse engineer what the bug you fixed was, which is why vulnerability embargoes can be helpful.
Exactly how does a permanent paid $100k salary change the "vulnerability embargo" window in this particular case?
E.g. the log4j JNDI code fix was night of December 4: https://github.com/apache/logging-log4j2/commit/d82b47c6fae9c15fcb183170394d5f1a01ac02d3 https://github.com/apache/logging-log4j2/commit/d82b47c6fae9...
The widespread news of the RCE was December 9.
How does extra funding change the timeline and coordinate a better embargo? Or asked another way, how do the commercial vendors manage voluntary information embargos better because they have dedicated paid staff?
- dathinab 5y ago> Commercial software with well-paid programmer employees also have long lists of CVE/RCE including MS Windows, Azure, AWS, Adobe PDF reader, Oracle database, etc. Exactly that. What paying some dev for open source work does is give you more ways to influence the direction of the projects. It can help you to put priority on fixing bugs which affect you. But it can't magically make disclosure work better. Also I would be surprised if some bad actors haven't already known this vulnerability for a while, and hence any more delay before disclosure would have been irresponsible. In general a full disclosure shortly after finding and fixing it is often the most responsible thing to do.
- whoisburbansky 5y agoIf there is evidence that a vulnerability is actively being used by an adversary, sure, it’s more responsible to disclose sooner, but in general you want to take into account the fact that the vast majority of engineering organizations aren’t set up to patch and/or update on a dime, which means that if you disclose immediately you now have a window of time in which anybody with a pulse and an internet connection can exploit the vuln, which is why a 90 day disclosure period is usually practiced.
- MayeulC 5y ago> What paying some dev for open source work does is give you more ways to influence the direction of the projects. It also gives you assurance that the project maintainer is able to maintain that project full-time, and will not be otherwise occupied at $dayjob when a CVE arises. If a maintainer can only spend spare time on a project, its state can degrade pretty quickly.
- seoaeu 5y agoIt can make disclosure work better for you. Specifically, a developer on your payroll (and with the associated working relationship that entails) is much more likely to let you know about a vulnerability ahead of the general public.
- stedaniels 5y agoCoordinating with CSIRTS and the big security vendors, think WAFs, XDRs, etc., would allow the impact of a disclosure to be heavily mitigated.