News for hackers. Stuff that matters.

A comment on Libxml2's "no security embargoes" policy. Parent comment

Re:Libxml2's "no security embargoes" policy by yeyeyeyeyeyeyee on Thursday June 26, 2025 @02:43AM (#44384791)
A basic definition of a security bug is something that violates confidentiality, integrity or availability.

A DoS affects the availability of an application, and as such is a real security bug. While the severity of it might be lower than a bug that allows to "empty bank accounts", and fixing it might get a lower priority, it doesn't make it any less real.

[ Parent | on HN ]
Re:Libxml2's "no security embargoes" policy by citrin_ru on Thursday June 26, 2025 @02:52AM (#44384859)
The problem is that DoS is the most vaguely defined category. If a library processes some inputs 1000 slower than average one may claim that this is a DoS. What if it is just 10x slower? Where to draw the line? What is the problem domain is such that some inputs just take more time and there is no way to 'fix' it? What if the input comes only from a trusted source?
[ Parent | on HN ]
Re:Libxml2's "no security embargoes" policy by thinkharderdev on Thursday June 26, 2025 @06:48AM (#44386086)
The CIA triad is a framework for threat modeling, not a threat model in and of itself. And what those specific terms mean will also be very system-specific.
[ Parent | on HN ]
Re:Libxml2's "no security embargoes" policy by jcelerier on Wednesday July 02, 2025 @02:41PM (#44447335)
> A basic definition of a security bug is something that violates confidentiality, integrity or availability.

who decided that "availability" was part of security?

[ Parent | on HN ]