News for hackers. Stuff that matters.
Re:Libxml2's "no security embargoes" policy by arp242 on Wednesday June 25, 2025 @07:23PM (#44382731)
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.

Re:Libxml2's "no security embargoes" policy by nicce on Wednesday June 25, 2025 @08:12PM (#44383023)
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

Re:Libxml2's "no security embargoes" policy by int_19h on Wednesday June 25, 2025 @11:10PM (#44383882)
Great, then we have someone with both resources and an incentive to write and maintain an XML parser with strict availability guarantees.
Re:Libxml2's "no security embargoes" policy by fodkodrasz on Thursday June 26, 2025 @05:49AM (#44385769)
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.
Re:Libxml2's "no security embargoes" policy by fodkodrasz on Thursday June 26, 2025 @05:45AM (#44385743)
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.