Most active commenters
  • nicce(4)
  • arp242(3)

←back to thread

Libxml2's "no security embargoes" policy

(lwn.net)
277 points jwilk | 14 comments | 25 Jun 25 19:36 UTC | HN request time: 0.003s | source | bottom
Show context
arp242 ◴[25 Jun 25 22:06 UTC] No.44382233[source]▶
A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet.

Things like "panics on certain content" like [1] or [2] are "security bugs" now. By that standard anything that fixes a potential panic is a "security bug". I've probably fixed hundreds if not thousands of "security bugs" in my career by that standard.

Barely qualifies as a "security bug" yet it's rated as "6.2 Moderate" and "7.5 HIGH". To say nothing of gazillion "high severity" "regular expression DoS" nonsense and whatnot.

And the worst part is all of this makes it so much harder to find actual high-severity issues. It's not harmless spam.

[1]: https://github.com/gomarkdown/markdown/security/advisories/G...

[2]: https://rustsec.org/advisories/RUSTSEC-2024-0373.html

replies(13): >>44382268 #>>44382299 #>>44382855 #>>44384066 #>>44384368 #>>44384421 #>>44384513 #>>44384791 #>>44385347 #>>44385556 #>>44389612 #>>44390124 #>>44390292 #
nicce ◴[25 Jun 25 22:11 UTC] No.44382268[source]▶
> A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet.

That is not true at all. Availability is also critical. If nobody can use bank accounts, bank has no purpose.

replies(5): >>44382300 #>>44382443 #>>44382474 #>>44382869 #>>44383755 #
1. bogeholm ◴[25 Jun 25 22:17 UTC] No.44382300[source]▶
Security and utility are separate qualities.

You’re correct that inaccessible money are useless, however one could make the case that they’re secure.

replies(4): >>44382341 #>>44382350 #>>44382887 #>>44383068 #
2. nicce ◴[25 Jun 25 22:26 UTC] No.44382341[source]▶
I think you are only considering the users - for the business provider the availability has larger meaning because the lack of it can bankrupt your business. It is about securing operations.
replies(3): >>44382398 #>>44382482 #>>44382532 #
3. marcusb ◴[25 Jun 25 22:27 UTC] No.44382350[source]▶
https://www.sentinelone.com/cybersecurity-101/cybersecurity/...
4. leni536 ◴[25 Jun 25 22:36 UTC] No.44382398[source]▶
Virtually all bugs have some cost. Security bugs tend to be more expensive than others, but it doesn't mean that all very expensive bugs are security bugs.
5. em-bee ◴[25 Jun 25 22:46 UTC] No.44382482[source]▶
not paying rent can get you evicted. and not paying your medical bill can get you denied care. (in china most medical care is not very expensive, but every procedure has to be paid in advance. you probably won't be denied emergency care so your life would not be in immediate danger, but sometimes an optional scan discovers something life threatening that you weren't aware of so not being able to pay for it can put you at risk)
6. arp242 ◴[25 Jun 25 22:52 UTC] No.44382532[source]▶
If a panic or null pointer deref in some library causes your entire business to go down long enough that you go bankrupt, then you probably deserve to go out of business because your software is junk.
replies(1): >>44382657 #
7. nicce ◴[25 Jun 25 23:10 UTC] No.44382657{3}[source]▶
I believe you know well that bankrupt is the worst case. Many business functions can be so critical that 24h disturbance is enough to cause high financial damages or even loss of life. A bug in the car's brakes that prevents their usage is also denial of service.
replies(1): >>44382731 #
8. arp242 ◴[25 Jun 25 23:23 UTC] No.44382731{4}[source]▶
Or 24h disturbance. Or indeed taking the entire system down at all.

And no one is talking about safety-critical systems. You are moving the goalposts. Does a gas pedal use a markdown or XML parser? No.

replies(1): >>44383023 #
9. hsbauauvhabzb ◴[25 Jun 25 23:51 UTC] No.44382887[source]▶
Inability for drug dispensers to dispense life saving drugs due to DoS has failed utility and will cost lives, would you describe that as secure?
10. nicce ◴[26 Jun 25 00:12 UTC] No.44383023{5}[source]▶
The point was about the importance of availability.

> Does a gas pedal use a markdown or XML parser? No.

Cars in general use, extensively: https://en.wikipedia.org/wiki/AUTOSAR

replies(2): >>44383882 #>>44385743 #
11. burnt-resistor ◴[26 Jun 25 00:21 UTC] No.44383068[source]▶
Define what you mean by "security".

Control integrity, nonrepudiation, confidentiality, privacy, ...

Also, define what you mean by "utility" because there's inability to convert a Word document, inability to stop a water treatment plant from poisoning people, and ability to stop a fire requiring "utility".

12. int_19h ◴[26 Jun 25 03:10 UTC] No.44383882{6}[source]▶
Great, then we have someone with both resources and an incentive to write and maintain an XML parser with strict availability guarantees.
replies(1): >>44385769 #
13. fodkodrasz ◴[26 Jun 25 09:45 UTC] No.44385743{6}[source]▶
AUTOSAR xml-s are compile-time/integration time toolchain metadata mostly in my memory.

Yet this is off topic for the libxml funding/bug debate.

For embedded mission critical C libxml is surely unsuitable, just like 99.99% of the open source third party code. Also unneeded. If crashes the app on the developer machine or in the build pipeline if it runs out of memory? Who cares (from a safety point of view)? That has nothing to do with availability of safety critical systems in the car.

14. fodkodrasz ◴[26 Jun 25 09:49 UTC] No.44385769{7}[source]▶
Automotive companies pay big buck to vendors who supply certified tools/libraries, because getting stuff certified is lot of work/time. This also means that those stuff are often outdated, and a pain to work with, yet their vendors are not expected to function as charities, as often expected by FLOSS authors, esp. when releasing their code under BSD/MIT licenses and then getting eaten by the sharks.