Thanks, this is really interesting.

I feel like it adds more weight to my feeling that we should have a software building code. When you have software that's critical infrastructure, with a nutso security policy like "no embargoes / 0day me bruh", we should have some regulations in place to require the software be maintained properly (that is to say, in a sane manner) or you can't use it commercially or for safety-critical things. Which would inevitably force commercial entities to pay for the maintenance so it could be done right.... which they should be doing already, the same way any company that builds safety-critical infrastructure has to pay to do it right.

If we want society to be safe, we have to make a law that enforces it. That's how that shit works.

(as an aside: holy shit, you're a prolific HN submitter, and all from different sources. where do you get it all?)

▲ Snild 5 days ago | parent | next [-]

> we should have a software building code

This made my brain go "Oh no, not this again. Open source projects don't owe you..." etc etc.

> or you can't use it commercially or for safety-critical things

Oh. Yeah, okay, absolutely! For safety-critical, I would like to think the responsibility already lies with the integrator/seller, but making it explicitly so can't hurt.

▲ WJW 5 days ago | parent | next [-]

> or you can't use it commercially or for safety-critical things

The license for libxml2 (like the license for almost any kind of open source software) already states "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT." I don't see how you can put the responsibility even more on the integrator/seller than that. It literally states the devs don't even guarantee it works correctly.

▲ elcritch 5 days ago | parent | prev [-]

Safety critical fields like aviation already have strict requirements. Usually there's very few software dependencies used in those projects.

Expanding that to more fields would be interesting, but difficult and expensive across the board. Particularly any sort of requirements like that generally incur significant regulatory and certification overhead.

However, if it was done similar to PCISS as an industry forum it might work better. Especially if certain fields like anything connecting with the electric grid we're required to use certified software.

	▲	4 days ago \| parent \| next [-]
		[deleted]
	▲	0xbadcafebee 4 days ago \| parent \| prev [-]
		Pretty much all construction uses materials which follow a specification. The least we could do is start requiring all commercial software do the following: `1. Declare an SBOM 2. Each software component must have a listed specification` We'd then need to make software specifications. Start with the most basic specification possible; "has performed linting", "has full integration test coverage", "has passed QA testing", "has an active maintainer", "lists its license", "does not have a hidden back door", "is free of known vulnerabilities", etc. Make more detailed specifications as-needed (for a particular industry, use case, requirements). Once we have all that, you can glance at a company's SBOM and find out if they've done the bare minimum due-diligence. We could also make or modify regulations that require these same materials standards, like privacy regulations, financial regulations. And yes, meeting minimum material standards is more expensive. We already accept that cost in the physical world, why not in the software world? If there's a TDS, SDS, MSDS, etc for physical products, we should have them for software too. I want to know your materials are safe before I use your products. I'm sick of being exposed by companies who are completely irresponsible.

▲ pcdavid 5 days ago | parent | prev | next [-]

Isn't this what the european Cyber Resilience Act (CRA) is about? See https://orcwg.org/cra/ and the work of the Open Regulatory Compliance Working Group in general.

▲

rcxdude 5 days ago | parent [-]

More or less, though the CRA is pretty minimal: it has a few basic requirements and hobby/unpaid open source software is not covered. A company integrating open source software is essentially responsible for covering those requirements themselves.

	▲	jeroenhd 5 days ago \| parent [-]
		The company being responsible for the open source components they integrate should solve the biggest dependency problems, though. From a security perspective, it doesn't really matter if a company fixes the bugs themselves or if they pay someone to fix it for them.

▲ Joker_vD 5 days ago | parent | prev | next [-]

> When you have software that's critical infrastructure, with a nutso security policy like "no embargoes / 0day me bruh",

...you then should stop and re-evaluate your life choices: specifically, choosing this particular piece of software, which is known to have always been insecure, to be a critical part of your infrastructure.

▲ tinco 5 days ago | parent | prev [-]

People building "safety critical" systems already pay for a "secure" ecosystem. It's called Microsoft. We don't need regulations to have Microsoft exist. Do you think some random med tech startup is going to pay to have libxml2 maintained? They'll see the regulation and go "oh ok, Windows licenses it is".

It's not the "safety critical" software that needs this fixed, it's all software in general. There's a million software systems that have important privacy sensitive data or safety relevant processes that fly under the "safety critical" radar.

▲

thyristan 5 days ago | parent [-]

Read your Microsoft licensing agreement. If you don't have one, read the EULA for OEM windows. The warranty, fitness for purpose and damages exclusion is not as extensive as what the grandparent cited, but it basically boils down to "as limited as legally possible, and the most damages you will get is your license fee back". You also won't get a binding requirements document anyways, so you don't even really know what the software microsoft sells you is fit for. At any point in time, there could be some knowledgebase article saying something like "oh, and btw, don't do this because it breaks", so per their warranty agreement you signed they are free from any responsibility simply by documenting the problem.

Really safety-critical stuff like ASIL-D, ISO26262, IEC61508 (and tons of other magic numbers) isn't something you can buy from microsoft. At best, you can sometimes get a reseller to sign something a little more binding, but with tons of restrictions that basically boil down to "use the microsoft stuff for the readout gauges, but the critical control part goes somewhere else".

▲

tinco 5 days ago | parent [-]

It's not about warranties, it's about having a stable ecosystem with some guaranteed measure of maintenance. The point is not that there's even more stable and expensive options than Microsoft. The point is that there's very little space for OSS here. Go to any hospital and count the amount of Windows devices and compare that to the amount of other operating systems you see. The second something becomes even a little safety oriented, there's going to be proprietary software.

So when these regulations that OP would start to take hold, would we get companies to sponsor random open source dependencies like libxml2? Or would they gather around some stable proprietary ecosystem like Microsoft's and maybe some big innovative solutions built on top of Microsoft?

▲

thyristan 5 days ago | parent [-]

Even the "guaranteed measure of maintenance" is not guaranteed. You don't get an SLA on patches or bugfixes from microsoft. You don't get an uptime SLA. Its all "best effort" or worse "when we feel like it". And the few SLAs they give you, e.g. on cloud stuff, are useless because it basically is "get your money back for that month". And the SLA measurement is done by their own downtime announcements, so a complete joke. Software lifetimes exist and are published, but guess what? Within that lifetime, you get "updates", but nowhere do you get any kind of guarantee about what is updated, what is fixed, how fast, if ever.

And no kind of safety-oriented anything will run windows or any microsoft software. There is no windows edition of therac-25. The stuff you see in a hospital is normal workstation PCs for non-safety-relevant data entry and display. As soon as it becomes safety-relevant like controlling your heart-lung-machine, auto-dosing your medications, controlling the x-ray beam, you are far away from anything microsoft.

And actually, OSS is used more often in those safety-relevant settings. Why? Not because the OSS maintainers themselves would themselves provide any support, SLA or warranty. But because the nature of OSS provides third parties the possibility to certify, maintain and guarantee for their special 'safety-relevant-libxml2-fork'. Sometimes this is done by the device vendors themselves, sometimes they buy this from others. But it happens, and it is growing in frequency.

https://www.codethink.co.uk/news/trustable-software.html (Linux) https://access.redhat.com/en/compliance/iso-26262-asil-b (Linux) https://www.lynx.com/case-studies/secure-linux-medical-devic... (Linux) https://developer.arm.com/Tools%20and%20Software/Arm%20Compi... (clang/llvm)

There is tons more. Basically any compiler for safety-relevant embedded stuff is either clang or gcc under the hood. Linux is frequently encountered when the real-time requirements aren't too strict. With Linux also comes the usual Linux ecosystem of OSS libs and services. It won't look like your normal desktop OS, but quite a lot in that area is OSS.

Nothing at all from microsoft (except a useless BS certification "you can use Azure Devops as a code repo to store you ASIL-D code...").

	▲	hobs 5 days ago \| parent [-]
		Don't forget that microsoft is the only cloud provider who regularly has so much downtime and eye popping exploits against its cloud infra.