My point was that "C/C++" is not a language. "C and C++" is the only correct reference they made to the two languages.
They only mentioned Rust once as an example of a "memory safe" language, but did not elaborate as much as they pointed their finger at "C/C++". This is bad and unconvincing writing.
The need is certainly clear. The call this blog post makes urges action and provides useful guidance on how to get that action moving. However, without legislative forcing, no such action will occur, and we will remain in the current regime where market forces such as reputational tarnish remains the most powerful driver for security choices. In some markets there are customers that must comply with regulations in their respective market, thus causing software vendors to provide more security assurance, but this is a special case and not the general case that the post here is looking for.
> The software industry must not kick the can down the road another decade through inaction.
The software industry most assuredly will, unless legislatively forced or otherwise compelled by the industrial environment.
Increased liability/lawsuit-exposure seems like an efficient way to do it (certainly better than regulations with very specific criteria around how people should write software)
This liability is already non-zero. I wonder if the penalty fees are too low, or if there's some kind of legal shield that reduces the risk
Another one is higher insurance fees when using unsafe tooling, just like in other industries when hazardous substances are used, or there are higher accident rates.
I could see underwriting a sealed appliance, but it doesn’t seem feasible for anyone to underwrite a general-purpose computer with varying components and many programs interacting under a power user’s commands.
You already have the liability, you just don't realize it because nobody has tried to sue you over anything. Laws will provide specific behaviors that constitute liability, rather than the "anything we can prove was damaging."
At least a legal framework will tell you what you should and shouldn't be doing.
Today the disclaimers in most software and the non commercial nature generally insulates you from liability unless they can demonstrate some extreme situation like maliciousness. A regulatory framework that doesn’t carve giant holes in liability for open source will stifle it, as it will erode the giant hole being used today. In the context of the topic (memory safety and other issues in software used widely) you can’t divorce that from open source and just hold commercial software culpable for their compliance. By introducing some sort of regulatory structure around software quality you necessarily either exempt open source, leaving a huge surface area untouched, or you essentially kill non commercial contribution.
Any references to case law? AFAIK none really exists because it’s generally assumed that non commercial open source licenses with disclaimers are pretty legally resilient so haven’t been tested. But my scope is US only.
I see publications like this come out of CISA every so often, but they always follow a similar format: "security is a really big problem", "the industry is consistently failing to apply well-known solutions", "will you pretty please just get on top of this already?"
There is no regulatory body equivalent to the FTC or SEC or FDA for software, and it shows. Big software isn't magically more altruistic than big pharma or big agriculture or big finance. Given a choice between making huge amounts of money with very little overhead and raising overhead in order to protect consumers, they will consistently choose the former. It's high past time we have an agency with real teeth to regulate the software industry.
This is the same argument against universal healthcare: “oh but look how much it will cost”. Yeah, it’s a lot. It’s also less than the price tag of the current system.
Compared to paying $10,000 for a Windows license, yeah, I'm pretty much immune.
You people literally do not know what you're asking for, and you don't understand what would happen if you received it. When you stand on the shoulders of giants, it's bad form to kick the ladder away.
You don't want government-mandated security specs for software projects, that would be an absolute nightmare with prescribed "sanctioned" languages and checklists applied with zero understanding of the underlying subject matter (the threat model of a video game is exceedingly different than one for a medical device).
The real solution is to come up with a framework around data leaks and their disclosure with provisions for mitigations (à la GDPR, keep only the data you actually need).
Anything else will end up boiling down to "Java is the best language for everything" because Oracle spend $N on lobbying.*
If anything, I hope we’ve learned that node uptimes are unimportant. It used to be a badge of honor to show some system hadn’t been rebooted in $years. Now that just implies that there’s unpatched vulnerabilities and countless hand-made configuration changes that nobody remembers and that will be lost if the machine dies.
A sign of a responsible organization these days is how short-lived their hosts are. If every machine in an organization has an uptime less than a week, I feel pretty confident in that org’s ability to recover from a disaster. I also know it’s harder for attackers to keep a foothold once in the system, since everything is being constantly updated and reimaged.
Whenever we see a big mistake on these fields, it becomes a scandal. Whenever we see a big mistake in tech companies, it's just part of the daily news.
Regulatory capture is a risk. The FAA allowed the max to be certified, and resisted grounding it after accidents. That is terrible, and there were congressional enquiries and legal settlements in the billions for Boeing - including several specifically for manipulating and misleading regulators. That all sounds like an argument for better regulatory oversight rather than no regulation.
I was mentioning that it's a system as flawed as everything else if you just expect it to work.
Also I'd like this kind of direct life threatening decisions to become criminal charges (not just fines) for the ones signing them off, please, including in software regulations.
Those are easier to regulate. People research how large of a radiation dose is appropriate for an x-ray, or how long certain parts/materials can sustain what kinds of loads, and they can use this information to come up with appropriate regulations.
It's much harder to come up with the same kind of concrete regulations for software security (i.e., device must deliver no more than X dosage to patient). We might have to settle for forcing companies to carry exploit insurance, and make it easy to sue for breaches.
In aerospace? Extremely well. Software (in context) that is subject to DO-178 certification is generally more reliable than the plane hardware. This is an industry where the 737 MAX, a plane safer than driving per-mile, is considered a death trap because the standard for safety is being 1000x safer than driving.
The software in one of the highest reliability industries is one of the highest reliability components. Unlike in other industries, especially consumer electronics, where even in low reliability products the software is almost always the lowest reliability component.
To put a more concrete take on this. In consumer systems, 5 9s is viewed as a gold standard. A level to aspire to, not necessarily one to achieve. In critical aerospace systems, 9 9s is viewed as the minimum, a level to never drop below. Many systems see 12 9s or higher.
The minimum standard in aerospace is 10,000x higher than the maximum standard in consumer. And the software reaches and exceeds that standard. That is how far the gap is and how well it works.
However, the downside is the expense and time. But, this can be mitigated by only applying these techniques where it matters. A key component of the DO-178 standard is identifying how critical each portion of the software is. You then only apply the most rigorous techniques for the highest criticality pieces. Of course, this requires the pieces to be well isolated, so that errors in one piece of non-critical code can not affect critical code; otherwise the non-critical code is actually, transitively, critical and thus demands increased rigor.
These techniques are tried and true in the most demanding circumstances. It would be prudent to start from these expensive working standards and work downwards to invent cheap working standards rather than fixing cheap non-working standards into cheap working standards. I think every software developer here can attest to it being much easier to start from something working, no matter how crude, than to start from something broken.
I call BS on 12 9s. To actually meet that a system operating for all of the common epoch would have only 60 milliseconds of downtime. There is no way since Wilbur and Oliver that any aerospace system could accomplish enough runtime to be sure it isn't 11 nines instead.
As for your actual point most systems would be better with a GC'd memory safe language then the hard real time those specs you mention are written from.
I am not talking about individual airframes. I am talking about quality of service over the entire fleet. Note that I will be using terminology more fit for IT than actual safety-critical system terminology to highlight the analogous elements.
The DO-178 standards were instituted 30 years ago [1]. There are ~700 million passengers per year flying on commercial airlines in the US since 2003. Extrapolating that backwards to 1992, that would be ~20 billion service requests fulfilled. In 2019, the US averaged 1.57 trillion passenger miles over ~1 billion passengers resulting in a average flight of 1500 miles. That corresponds to around 3-4 hours on average at cruising speed. It takes around 3 minutes for a plane at cruising altitude to crash. So, since the DO-178 standards were introduced there have been 1.6 * 10^12 safety-critical service segments where a software failure over that period could cause a fatality.
There have been exactly zero fatalities connected to software errors since the DO-178 standard has been introduced. So, over 1.6 * 10^12 service segments every single one of them was successfully delivered by the software without failure. 12 9s.
Also, just in case it is not clear, calculating over multiple airframes does not result in redundancy reducing error rates. Every single airframe must succeed in their service of every single requested service. An analogous situation in IT would be having 10,000 servers with zero redundancy achieving 5 minutes of total downtime divided over all 10,000 servers resulting in 9 9s reliability.
You don't need to mandate the solution, just punish the negative outcomes. As long as Experian and their peers can get away with dumping gigabytes of data without any punishment, they will. Apply a generous fine to any data breach or an incident resulting in monetary loss incurred due to bad software, and you'll see things change.
> with prescribed "sanctioned" languages and checklists applied with zero understanding of the underlying subject matter
This is always brought up as a boogeyman every time regulation is proposed, but then we have stories about Incorporation by Reference [0], where Congress explicitly encourages agencies to incorporate standards written by industry groups into law. It's not a perfect system (for example, the copyright disputes), but it seems to work a hell of a lot better than the free-for-all we have right now in our industry.
> The real solution is to come up with a framework around data leaks and their disclosure with provisions for mitigations
Agreed. And an agency with teeth to enforce the framework. And the provisions for mitigations should have the force of law.
Even highly regulated fields like medicine or aerospace have frequent instances of irresponsibility for profit. Only fines that wipe out the profits of operating irresponsibly will get through them.
Conversely, we don't want to lose FOSS because single developers can't cope with the legal risks. Maybe there's opportunity for incentivizing cheap security certification of FOSS, or a CISA-approved subset of FOSS that is guaranteed to follow strict security practices.
I dont't think this would be a problem for FOSS. If I release an unsafe or not code compliant kitchen/house/etc. blueprint (and don't make claims to the contrary) nothing would happen to me. If I sell them the situation might be different. I think the same would apply to FOSS.
All that that strategy would mean is that the costs of security auditing would fall onto the business using the FOSS code. It will start looking very attractive to instead buy code from an established software vendor who will provide some level of liability guarantees and assistance in auditing rather than going it alone with FOSS and in-house or external auditing.
The costs of security auditing already fall onto the businesses using FOSS code, though. A business just blindly incorporating code without static analysis, vulnerability checks, etc is not exercising due care.
So basically, it would work like in every other industry? FOSS, for all the good it does, it also did break the economics of software. How much of the current problems with adtech, surveillance capitalism and VC funding stems from FOSS making it impossible to simply sell software components like products?
None of it. Emacs didn't kill word or Wang or WordPerfect. OS vendors still make money despite Linux and FreeBSD. The GIMP didn't kill Adobe. And if you want to sell proprietary libraries your market is going to be limited because OSs will distribute them and it will be hard to keep up when customers are fixing their own problems.
What killed the shrink-wrapped market was first piracy and secondly the way people use their computers change. Then add on the easy sharing that e.g. Google docs enables and it's all over but the shouting.
The SAAS model also has the benefit of aligning value delivery with outlays temporally. No more wait a year before shipping: instead get quick iteration with an ongoing revenue stream. You can recover from missteps in a way that the old model could not.
Not sure how to respond to that. Emacs is around, the latter two I believe not, but approximately nobody is using them anyway. And I say that as someone who lives in Emacs.
> OS vendors still make money despite Linux and FreeBSD.
Apple makes money on hardware. Microsoft makes money on cloud, and has been desperately trying to turn Windows into a subscription service for a while now. They even non-humorously said exactly this in some message in (IIRC) installer or update screen - I remember Windows 10 telling me "Windows is a service" as if that was a good thing.
> The GIMP didn't kill Adobe.
No, but again, GIMP and Krita are used by approximately no one, meanwhile Adobe switched to a quite abusive subscription model.
> And if you want to sell proprietary libraries your market is going to be limited because OSs will distribute them and it will be hard to keep up when customers are fixing their own problems.
I don't see how. Think about the 100 (or 10 000, if you're doing webdev) dependencies your product uses. Most of those could be a licensed product, creating a cottage industry of small vendors making a living from developing specialized libraries. This thing is real in some areas, e.g. industrial software, where there are e.g. protocols that are too complex and boring for Open Source community to care about supporting in full. But it's something impossible in general, because popularity of open source simply prevents this kind of market from forming.
Now, to be clear: I don't have a strong opinion on whether this is good or bad. Still trying to fully understand that one. But what I know for sure is that open source is a huge disruption to how the market would've worked otherwise.
> What killed the shrink-wrapped market was first piracy
I'm not convinced about that. Maybe video games had a problem, but money in software in general was in B2B, not B2C, and there the piracy was effectively mitigated by the legal system. In fact, both Microsoft and Adobe used piracy as opportunity because of that - kids would grow up using pirated copies of professional software, and then as adults, their companies and their employers would have to buy the properly licensed versions of that same software, because that's the only thing anyone has experience in using.
> The SAAS model also has the benefit of aligning value delivery with outlays temporally. No more wait a year before shipping: instead get quick iteration with an ongoing revenue stream. You can recover from missteps in a way that the old model could not.
SaaS has some benefits, but they tend to be single-sided, unless the customer and the vendor are comparable in power, which usually isn't the case. So while e.g. IBM or Microsoft can force Google or Adobe to behave, my small business will be taken advantage of by large SaaS vendors.
Oh my gosh. It's not FOSS that kills software, it's ctrl-c and ctrl-v.
Computers always allowed you to copy code for free and any new concept that took six months to be made up, can be duplicated for free in one second.
The real problem is that you have to ship code that can be disassembled and read by another human being, to sell software. This fact annihlates any incentive and control an author-of-software has over their conceptual labor.
What we need is a method to sell a binary (and source-code) that are completely free of human-perceivable information AND authorized against a purchase server. Identify the code author or not, both are fine, what matters is the conceptual labor is protected.
That's it. We do that and it becomes viable to do hard mental work for a long time, and take risks on bold moves. Make the concept work and sell the baked end result without giving away the recipe.
Every other industry keeps the means of production to themselves.
But for some awful reason, programmers are expected/required to ship the means of production, the understanding of the code and the concepts of the code AND be ready to answer anything, in a relationship with the purchaser.
The balance of effort between software developers and the benefit everyone else gets from them, is completely messed up.
> What we need is a method to sell a binary (and source-code) that are completely free of human-perceivable information AND authorized against a purchase server.
That sounds impossible in principle, not without taking away ownership of the machine from the user. I guess TPM + homomorphic encryption might allow this one day, but that doesn't feel like a win for society.
> But for some awful reason, programmers are expected/required to ship the means of production
Pedantic, perhaps, but I wouldn't classify code as "means of production". Dev tools and supporting tooling, maybe, which no one is required to ship.
I sort of agree with you're saying overall - you're pointing out the fundamental issue, open source is just something enabled by it. I focused on open source because, arguably, this reality of "messed up balance" was still manageable through the legal system, and it's the FLOSS becoming a cultural phenomenon in the industry that broke this.
You misunderstood. In the scenario you replied to, you give a piece of cake, to someone who then sold it to someone else. They are the vendor, not you.
They won't, because they'll need to find an insurer willing to underwrite it. Good luck getting liability and omissions coverage without an established business entity or licensure. Insurers themselves want to know you are following the law rather than fly by night operations.
I mean, there's a reason most FOSS software licenses contain some variation of "THIS SOFTWARE IS PROVIDED 'AS IS' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES..."
>> If you pay for software it generally comes with some warranty and guarantee of fitness for purpose.
Generally it does not:
Microsoft Windows EULA states:
"Disclaimer. Neither Microsoft, nor the device manufacturer or installer, gives any other express warranties, guarantees, or conditions. Microsoft and the device manufacturer and installer exclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement. If your local law does not allow the exclusion of implied warranties, then any implied warranties, guarantees, or conditions last only during the term of the limited warranty and are limited as much as your local law allows. If your local law requires a longer limited warranty term, despite this agreement, then that longer term will apply, but you can recover only the remedies this agreement allows."
"Disclaimer of Warranties; Limitation of Liability
THE PROGRAMS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ORACLE FURTHER DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT."
Microsoft doesn't provide any guarantee of fitness for use, and you blame that on software engineers being uncertified? Blame it on Microsoft!
(Now, there might be an argument you could make that, if software engineers had actual certifications, they would have the leverage to push back against Microsoft management and say "no, we're not going to ship that". But I'm pretty sure that wouldn't work, at least not at this stage of the game. Microsoft would just find coders in India or the Philippines or somewhere to implement it where there are no such professional regulations. No, when a company the size of Microsoft does something like that, the problem is not with the individual contributors.)
Even in places where Engineers are distinct from Developers (see Canada above), it's not common to learn code safety as a core principle for writing good software. Safety critical and real-time software principles are topics often left to upper year electives.
My university (UNSW in Australia) had a compulsory “Ethics for software engineers” course as part of my CS degree. It was shockingly interesting and relevant. We studied various ethical frameworks, went through case studies about bad software killing people and had class debates and things.
An ethics course is no panacea. But what I learned in ethics has been far more useful in my career than a lot of my hard CS subjects.
Yeah. I don’t think engineering certifications are needed. But I do think it should be illegal for companies to avoid legal liability for their products like this.
I mean, you don’t sign a 20 page contract when you visit a restaurant saying you agree not to sue them if you get food poisoning. Or sign something saying you take responsibility if you die in a plane crash, or from a shoddy building collapsing on your head. Companies in all other areas of society are held responsible for foreseeable harm caused by the products they sell. EULAs make a mockery of that, and the law should void or ban them.
Software has catastrophic bugs that make it more like house of card engineering than building engineering. But sure we can make NASA-grade programs, for NASA prices. Or actually we can’t, because there is an extremely limited supply of such scientists, who would also accept to work on a boring data entry app.
Software also suffers of untold expectations. Companies regularly spend as much time writing specs as developing the real software, and yet, imprecision still dominates the implementation.
I assure you, software engineers have zero say in the licensing decisions beyond the size of a small corp. It's all the management and lawyers at work.
In fact, in the US, if you get a licensed engineer to do an inspection or design job, they will also often include a list of disclaimers to avoid liability. You often have to negotiate the lack of said liability waiver in advance for a higher fee. Note, liability waivers don't protect from negilence, just all other scenarios.
Only high-level legal wizards and magisters can go there and expect to understand anything and keep their sanity.
Not a lawyer, but I expect it comes down to "if you follow our guidelines and pay us enough we can make the following guarantees, but there are certain things that we simply do not cover."
Yes, but it is not for consumers. It is for big businesses that pay millions and have specific expectations. The more you are willing to pay to more you can get within specific limits.
Your original statement, "If you pay for software it generally comes with some warranty and guarantee of fitness for purpose." does not hold for consumers and only partially holds for enterprise customers.
It might be better stated: "If your business / entity / government has specific needs (e.g. compliance with legal or medical regulations, industry certifications, ISO requirements, auditing, etc.), has a large sack of money to pay, and a team of lawyers, then there are some software publishers who will sign contracts to guarantee you certain qualities about the software you license with them and perhaps some level of support of that software."
Limited Remedy. If Microsoft, or the device manufacturer or installer, breaches its limited warranty, it will, at its election, either: (i) repair or replace the software at no charge, or (ii) accept return of the software (or at its election the device on which the software was preinstalled) for a refund of the amount paid, if any.
FOSS has nothing to do with that. Companies providing products based on FOSS need to do their homework and check what they're using. If they can't guarantee that the FOSS library is reliable, they shouldn't use it.
No one size fits all regulatory quality requirement works.
What needs to be done in commercial software, as is done in all other industries and in existing safety-critical software deployments, is segregating use cases by criticality and requiring deployments reach and guarantee the necessary quality level for that criticality class. It is the job and liability of the deployer to guarantee the requirements are met. They may push these requirements down to their suppliers, but it is the deployer that is ultimately responsible.
This is why Home Depot is not required to only sell aircraft-grade rivets. It is the airplane manufacturer’s job to source adequate components, not the job of all component suppliers to guarantee their components are fit for all possible purposes.
Under this model you can release any software you want. It is the manufacturer using the software that bears the burden of proving it is adequate. Or, if the software maker want to voluntarily take on extra burden, the software maker can verify and certify that the product is adequate for whatever purpose they wish to support.
Quality where it is necessary, and flexibility where it is not.
You're saying you think defective planes/poorly trained pilots would be less common in the complete absence of rules regarding certification of pilots or airframes?
If anything, Boeing 737MAX demonstrates how effective regulations have been. I bet you'd have to look up another similar event, because they are so rare.
People lost their shit over the 737MAX. Boeing lost a ton of money and credibility. It made everyone realize that strong regulations need to be maintained and how it's a bad idea to allow manufactures to review their own product. It's also likely to result in even more regulations and a executives at Boeing being criminally tried.
Regulations are incredibly effective, but you can't go soft because they are working. Regulators have to be ever vigilant and politicians who push for softening of regulations need to be voted out of office. We are finally starting to see that conspiracies to skirt regulations constitute criminal behavior by senior company leadership, this is a good thing for the public.
>and politicians who push for softening of regulations need to be voted out of office.
I'm not sure I really see a distinction between that and a hardline tough on crime position. Not all laws/regulations are good and even an ensemble of individually good rules could be problematic in aggregate. Though in the current political climate, I would tend to agree that those pushing for reducing regulation are mostly not doing so as part of a well-intentioned effort to reduce adverse effects of regulation for the public good.
“There are two novels that can change a bookish fourteen-year old’s life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs"
It's interesting that, in light of things like this, you still see large software companies adding support for new components written in non-memory safe languages (e.g. C)
According to the github page for crun, it's because it's more performant and uses less memory and because the authors feel it is a better fit for a lower level container runtime. C code runs on more systems than Go does as well. I'm assuming that will stop being true at some point, but as of now C runs basically everywhere.
It's also worth noting from the linked docs that crun was added as an option in OpenShift. runc is still the default container runtime, and which runtime to use is customizable on a per-MachineConfigPool basis[0]. Cluster admins have the ability to specify node groups that have application workloads requiring the performance of crun to use it.
> OpenShift Container Platform uses CRI-O as the container engine and runC or crun as the container runtime. ->The default container runtime is runC.<- Both container runtimes adhere to the Open Container Initiative (OCI) runtime specifications.
As for Rust-written runtimes, there is another project in the Containers GitHub namespace called youki[1] that is attempting to do just that.
It creates a record of ignored warnings that can then be cited as justification for regulatory intervention. At this point, I think something onerous is inevitable.
The vast majority of security breaches, large and small, start with someone clicking a link to a malicious place from an email that probably wasn't even that sophisticated. How does rewriting the entire world in rust fix that?
While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it. The gaslighting from certain vocal proponents of C++ has been a major stumbling block for the industry as a whole to move on to using memory safe languages in critical software layers.
It was never a good idea to use a performance-oriented language for software that should have had its highest priority as security, and it will be remembered in the long tail of history in the same way that asbestos is: a hazardous material that took us a long time to rid ourselves of.
not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. Red Hat is one of the companies that also has a strange C addiction for almost anything.
There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.
Go is tough to get approved in certain Red Hat markets. Simply because it calls out to github for packages without an audit tool. A lot of finance companies have blocked the use of Golang because of that. Totally fine with Java and their own Nexus. Same with Javascript and their own NPM on Nexus. But they can't see past `go get github.com...`
When they totally could be doing `go get sources.redhat.com...`
Go has a thing for that now- everything goes through a proxy (https://proxy.golang.org), and if you set GO_PROXY, you can send it through your proxy (Nexus et al).
I don't know for Go case how it would work, but what I saw in case of Maven is it's company wide blocked and you have to get your packages through Sonatype Nexus - and Nexus either has it's own packages or it has a proxy for Maven packages. So I wonder in case of Go, if it would be unfeasible to block GitHub so they would just block the entire use of the language in company developed software.
exactly. If you block go packages via firewall IT rules, you block github.com software engineering work. It's the one thing I think that's holding Golang back. Deno as well. I know it looks novel but it's a security nightmare.
yeah, go modules have streamlined golang development so much. Providing a custom domain configuration on your site allows go to grab the code vs a user visiting it in their browser.
>not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago.
You say "just 8 years ago" but another way of phrasing that would be "only 4 months after Rust went 1.0". And that's the first release, which means work probably started before Rust went 1.0
>Red Hat is one of the companies that also has a strange C addiction for almost anything.
This is kinda true and I wish it was different, but most of the examples people bring up are ones like the one you brought up. Rust wasn't a "safe choice" at the time they were started.
There's other factors too, like needing to support POWER and Z architectures. If you have a lot of such products written in C, and you have a GCC toolchain team in-house, that's not so difficult. If you have a lot of such products written in Rust, and your LLVM toolchain team is much smaller and the compiler itself less mature on those platforms, it's a bit more challenging. And then the whole issue of dynamic vs. static linking, where there's a ton of organizational inertia in favor of the former.
All that said I think the list of valid excuses is increasingly small nowadays.
As long as the Rust community doesn’t fuck up Rust, it looks like that transition, and more importantly the broad recognition of its necessity and feasibility, is well underway.
C was my first love as an adult programmer. I still enjoy its economy and expressiveness, even though I've written no production code in it for over a decade. So it saddens me, but I agree: it's time to retire C and C++, and put some serious work into migrating security/safety critical codebases to more robust languages.
Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people choose to use them), not from the demand side (shame people into adopting Rust).
I think there is a significant portion of developers that want to leave C++ for a better language, but for different reasons may not be satisfied with Rust or Go, so they just stay on C++.
What's wrong with Python, Java, C#, etc? Conversely, while better at avoiding footguns than C, Zig doesn't provide quite the same memory safety - although to be fair, better is still worth it.
Security is not the only dimension that matters, resource efficiency and scalability matter too. A big driver in the use of C++ is that it is more efficient than Python, Java, etc by an integer factor in real workloads. No one wants to increase data center sizes by 4x (or more) to run the same workload. Being that wasteful isn't environmentally friendly.
I am certain that one of the reasons Swift uses reference counting is to achieve more predictable performance and to avoid the GC pauses that plague Java etc.
Another may be that it simplifies the runtime for system code such as kernels and device drivers.
It's not just that, reference counting is friendlier to non-uniform memory access, which is what you have on a system with swap and/or memory compression. In compacting GC, the compacting part can help here, but the GC part doesn't.
But people do use GC on their phones, insofar as they like to use web browsers.
Swift uses reference counting, because it interoperates with the Objective-C runtime, duh.
.NET interop with COM is a good example of how mixing a tracing GC with a reference counted runtime requires an higher engineering budget that Swift team most likely wasn't willing to spend resources on.
It has been proven multiple times that reference counting is slower and has performance issues when dealing with large graphs, and also stop-the-world issues when cascade deletions occur.
If only pro-RC folks would bother to read CS papers and benchmarks.
I really don't see what issues there are with rust that could be addressed by another language without compromise on the performance and memory safety axes.
I can think of two reasons for people not moving: 1. inertia, aka "not going out of comfort zone to learn new things" ("learning" includes understanding why things are different, not merely knowing they are). This won't be addressed by another new language that people will also need to learn.
2. Existing codebases won't magically turn from C++ to Rust. Legacy is actually a good reason to still be using C++ today, but another language also won't address this, as the fundamental issue is you can't change the existing code to be safer without effort.
In both cases, time and effort on the language best positioned to replace C++ (Rust) will alleviate these issues. In particular this effort could be spent to fully close the feature gap with C++ (specialization, more expressive consts, ...) and improving Rust/C++ interoperability.
No need to "shame" people, but finding a way to replace C++ use by Rust use is how we will solve the problem.
> While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it.
This has largely happened already. Java is in fact a memory safe language which has replaced a whole lot of C++ code since the late 1990s. It's only in a few highly performance-oriented areas where the debate ("should we be replacing C++ with a memory safe language?") is still undecided.
Java may be memory safe, but errors in highly expressive functionality like Java serialization and expression parsers have been responsible for some of the most impactful vulnerabilities in recent memory.
CVE-2017-5638 was famously exploited to gain access to Equifax's network and cause a massive data breach. Log4Shell is continuing to cause problems in all kinds of networks due to the extremely widespread use of the Log4j library. Java is definitely an upgrade over C/C++, but there are definitely still security risks.
That is not the case in my experience. There are still plenty of C++ codebases that don't need the extra performance over something like Java or care about GC pauses.
C++ continues to be popular because it's a powerful language and can easily integrate with a ton of libraries, and most people don't care much about security.
There's too much friction for Rust to be the solution, unless there are drastic changes in the near future. None of Vulkan, Metal, GTK, Qt, Cocoa, Android, iOS, or Wayland have official Rust support, and maintaining the boundary is a non-trivial task.
My gut feeling is that a different language with less friction will gain more traction.
I think that is a reductive dismissal of a real problem. Rust is intended as a C++ replacement, but interfacing to existing C and C++ code can be very messy, it’s not just simple language bindings. What I’m suggesting is that the work needs to be spread out or it’s not likely to happen.
The premise is wrong. It's like saying that we need to more carefully design the copper wires so that they don't touch anything accidentally, instead of... you know... using insulators, and circuit protection.
You should be able to run any program you want, no matter who wrote it, nor the language used, safely. If you can't do that, your operating system sucks. Security is the operating system's job.
Just because we're collectively hotwiring everything to the computing grid, and just telling programmers, admins and users to be more careful, doesn't mean its a sane way to live.
To cope with our current insane situation, we've all discovered coping mechanisms, like putting things in VMs, Containers, using Sandboxes, etc... none of them are as effective as specifying at runtime exactly what side effects are allowed. The user can do it using powerboxes, the admin can do it in a batch file.
We can have easy to use, secure, general purpose computing, but at present, the Overton window is too far away for most people to see it as even possible.
I supposed it was like that with the electric grid at some point, too.
> Security is the operating system's job, not the application programmer.
That’s just flat out not true. It’s jot possible for an operating system to be perfectly secure without unduly locking down the capabilities of applications.
All you need, hardware wise, is an MMU that can protect the OS microkernel from abuse. Modern peripherals have their own software that also needs to be tamed.
Sounds nearly impossible unless you think Windows, MacOS, Linux, Unreal Engine, ROS and every real-time OS will be rewritten within 20 years. Plus infrastructure and ecoystems for so many other domains (e.g. audio, signal processing, telecom, simulation, aerospace). There's plenty of fresh young talent getting into these fields every year.
When I started coding, going all in using Assembly was perfectly normal, then C, Pascal, Modula-2 were all over the place, then Object Pascal, C++, Clipper, Delphi, then Java and .NET, then ....
It will take generations, doesn't make it impossible, and you already see this change happening in mobile OSes like Android, where C and C++ are frowned upon for regular app development other than games.
I'm only just learning about all this stuff so might be a somewhat naive question, but if we created some kind of operating system like plan9 that was coded in rust or another similar language, that offered compatibility for existing linux software, and then moved towards creating all new software in memory safe languages would this solve not only this problem but a lot of other problems also? I read today that containers and container management wouldn't need to be half as complex as they are today if plan9 had taken off the same way linux did. Would be a big, big effort but if a major player got behind it like AWS then maybe not impossible. Redox looks like an interesting attempt at creating something like this.
There is little incentive for the major players to invest in such a hugely expensive effort. Furthermore, a lot of software is running on non-Linux systems.
In my head, the incentive would be companies could save the time and effort that they're investing in Docker/K8s as well as getting better security because of the memory safety. Would that not be enough to warrant the shift, at least for software that is running on Linux systems? Feels like you could get rid of a lot of the Docker/K8s overhead which could translate into lower operating costs as well.
All that is needed to prevent remote exploits from taking effect is strong input/output sanitization, and firewall. It becomes next to impossible to exploit vulnerable software if you are limited to the characters you can send.
Most web services do this in the network level with load balancers that forward only a single port to the service VM that is otherwise behind NAT to prevent any access to any other program in the VM that is left listening on a port. You can extend this concept to the input and output processing of the service.
so many critical exploits use the same characters and lengths as intended inputs. Also, if firewalls were a replacement for secure code, no one would be talking about memory safety.
No. In order to exploit modern memory corruptions, you have to most often send a shitload of data with significant lengths to fill up memory strategically and/or rop gadget jump addresses. None of this looks like real payloads.
The analogy to firewalls is that you would specify the exact condition of the input for it to forward to the actual program. For example, if your endpoint receives json, you would validate the json and check each field value for valid range, ie min max number of characters and what those character values could be for each field. Just like a firewall limits who can talk to who in way.
In the same time I am teaching my daughter how to do buffer overflows with a board game I just released: https://punkx.org/overflow/
I think memory unsafety is what makes computers fun, ever since I read phrack 49/14 it made me see programs in a different light and actually enjoy programming way more.
In the same time I would like to not have zero click zero day exploits on my iOS phone where I cant control at all what code is executed.
"In what other industry would the market tolerate such well-understood and severe dangers for users of products for decades?"
The DoD funded Ada which curiously is not mentioned here.
The above sentence is also strange because it is not "the market" that "tolerates" dangers to the user (customer). It is the legislature that tolerates it. If it's legal and triggers no civil liability for a manufacturer to "sell" (a license to) a product that is dangerous, then why would it refrain from doing so. And further what if the customer has no viable alternative to "purchasing" (a license to) the dangerous product.
Sell and purchase are in quotes in the event we are referring to either (a) so-called "tech" companies that derive necessary revenue not from software (license) sales but from advertising services sales and/or (b) software companies that sell licenses to OEMs (customers) rather than directly to users. In neither case does the user actually purchase the software (license). In these cases, even if we assume, correctly or incorrectly, that users are "the market", it is arguable they have no meaningful choice of viable alternatives. This might explain why they "tolerate" dangerous software. If we assume, correctly or incorrectly, that advertisers or OEMs are "the market" then, as above, they "tolerate" dangerous software because legislatures have not made this illegal or a source of civil liability.
All the serious exploits I keep seeing these days are not memory safety related. Although it does continue to be a plague I really must challenge CISA to back up their call for urgency with breach stats.
While this is true for some categories of software, most code is completely disposable and likely doesn't see the light of day. CISA is solving different problems than most require.
194 comments
[ 4.7 ms ] story [ 391 ms ] thread"C and C++": 1 mention
"Rust": 1 mention
They only mentioned Rust once as an example of a "memory safe" language, but did not elaborate as much as they pointed their finger at "C/C++". This is bad and unconvincing writing.
> The software industry must not kick the can down the road another decade through inaction.
The software industry most assuredly will, unless legislatively forced or otherwise compelled by the industrial environment.
This liability is already non-zero. I wonder if the penalty fees are too low, or if there's some kind of legal shield that reduces the risk
Software can be installed on billions of devices. Even a low liability could be financially ruinous...
Especially for open source.
At least a legal framework will tell you what you should and shouldn't be doing.
Also outside computing industry everyone is liable on the eyes of the law, even if doing charity.
If the user has accepted such provision before making the binding acquisition of the said product, then it is another matter.
There is no regulatory body equivalent to the FTC or SEC or FDA for software, and it shows. Big software isn't magically more altruistic than big pharma or big agriculture or big finance. Given a choice between making huge amounts of money with very little overhead and raising overhead in order to protect consumers, they will consistently choose the former. It's high past time we have an agency with real teeth to regulate the software industry.
As long as you understand who will pay for it: you. Along with the rest of us.
This is the same argument against universal healthcare: “oh but look how much it will cost”. Yeah, it’s a lot. It’s also less than the price tag of the current system.
You people literally do not know what you're asking for, and you don't understand what would happen if you received it. When you stand on the shoulders of giants, it's bad form to kick the ladder away.
The real solution is to come up with a framework around data leaks and their disclosure with provisions for mitigations (à la GDPR, keep only the data you actually need).
Anything else will end up boiling down to "Java is the best language for everything" because Oracle spend $N on lobbying.*
*Replace Java/Oracle with another pair.
A sign of a responsible organization these days is how short-lived their hosts are. If every machine in an organization has an uptime less than a week, I feel pretty confident in that org’s ability to recover from a disaster. I also know it’s harder for attackers to keep a foothold once in the system, since everything is being constantly updated and reimaged.
But these days systems can be patched without restarting
So "uptime" is not necessarily accurate
Hazzard is a fictional county in Georgia that's the setting for the TV show “The Dukes of Hazzard”.
See the Boeing 737MAX fiasco for reference.
Regulations are pretty easy to circumvent with enough money it seems.
I was mentioning that it's a system as flawed as everything else if you just expect it to work.
Also I'd like this kind of direct life threatening decisions to become criminal charges (not just fines) for the ones signing them off, please, including in software regulations.
It's much harder to come up with the same kind of concrete regulations for software security (i.e., device must deliver no more than X dosage to patient). We might have to settle for forcing companies to carry exploit insurance, and make it easy to sue for breaches.
The software in one of the highest reliability industries is one of the highest reliability components. Unlike in other industries, especially consumer electronics, where even in low reliability products the software is almost always the lowest reliability component.
To put a more concrete take on this. In consumer systems, 5 9s is viewed as a gold standard. A level to aspire to, not necessarily one to achieve. In critical aerospace systems, 9 9s is viewed as the minimum, a level to never drop below. Many systems see 12 9s or higher.
The minimum standard in aerospace is 10,000x higher than the maximum standard in consumer. And the software reaches and exceeds that standard. That is how far the gap is and how well it works.
However, the downside is the expense and time. But, this can be mitigated by only applying these techniques where it matters. A key component of the DO-178 standard is identifying how critical each portion of the software is. You then only apply the most rigorous techniques for the highest criticality pieces. Of course, this requires the pieces to be well isolated, so that errors in one piece of non-critical code can not affect critical code; otherwise the non-critical code is actually, transitively, critical and thus demands increased rigor.
These techniques are tried and true in the most demanding circumstances. It would be prudent to start from these expensive working standards and work downwards to invent cheap working standards rather than fixing cheap non-working standards into cheap working standards. I think every software developer here can attest to it being much easier to start from something working, no matter how crude, than to start from something broken.
As for your actual point most systems would be better with a GC'd memory safe language then the hard real time those specs you mention are written from.
The DO-178 standards were instituted 30 years ago [1]. There are ~700 million passengers per year flying on commercial airlines in the US since 2003. Extrapolating that backwards to 1992, that would be ~20 billion service requests fulfilled. In 2019, the US averaged 1.57 trillion passenger miles over ~1 billion passengers resulting in a average flight of 1500 miles. That corresponds to around 3-4 hours on average at cruising speed. It takes around 3 minutes for a plane at cruising altitude to crash. So, since the DO-178 standards were introduced there have been 1.6 * 10^12 safety-critical service segments where a software failure over that period could cause a fatality.
There have been exactly zero fatalities connected to software errors since the DO-178 standard has been introduced. So, over 1.6 * 10^12 service segments every single one of them was successfully delivered by the software without failure. 12 9s.
Also, just in case it is not clear, calculating over multiple airframes does not result in redundancy reducing error rates. Every single airframe must succeed in their service of every single requested service. An analogous situation in IT would be having 10,000 servers with zero redundancy achieving 5 minutes of total downtime divided over all 10,000 servers resulting in 9 9s reliability.
[1] https://en.wikipedia.org/wiki/DO-178B
Especially when some plane models need to be rebooted every couple of weeks because of software bugs ;)
https://www.theregister.com/2020/04/02/boeing_787_power_cycl...
If a major company got liquidated for extreme negligence, even once in a while, security would be much more in the forefront of executive's minds.
This is always brought up as a boogeyman every time regulation is proposed, but then we have stories about Incorporation by Reference [0], where Congress explicitly encourages agencies to incorporate standards written by industry groups into law. It's not a perfect system (for example, the copyright disputes), but it seems to work a hell of a lot better than the free-for-all we have right now in our industry.
> The real solution is to come up with a framework around data leaks and their disclosure with provisions for mitigations
Agreed. And an agency with teeth to enforce the framework. And the provisions for mitigations should have the force of law.
In other words: we need regulation!
[0] https://news.ycombinator.com/item?id=37498473
Thankfully, it does not contain prescribed languages, just functionalities and things you have to do.
Conversely, we don't want to lose FOSS because single developers can't cope with the legal risks. Maybe there's opportunity for incentivizing cheap security certification of FOSS, or a CISA-approved subset of FOSS that is guaranteed to follow strict security practices.
What killed the shrink-wrapped market was first piracy and secondly the way people use their computers change. Then add on the easy sharing that e.g. Google docs enables and it's all over but the shouting.
The SAAS model also has the benefit of aligning value delivery with outlays temporally. No more wait a year before shipping: instead get quick iteration with an ongoing revenue stream. You can recover from missteps in a way that the old model could not.
Not sure how to respond to that. Emacs is around, the latter two I believe not, but approximately nobody is using them anyway. And I say that as someone who lives in Emacs.
> OS vendors still make money despite Linux and FreeBSD.
Apple makes money on hardware. Microsoft makes money on cloud, and has been desperately trying to turn Windows into a subscription service for a while now. They even non-humorously said exactly this in some message in (IIRC) installer or update screen - I remember Windows 10 telling me "Windows is a service" as if that was a good thing.
> The GIMP didn't kill Adobe.
No, but again, GIMP and Krita are used by approximately no one, meanwhile Adobe switched to a quite abusive subscription model.
> And if you want to sell proprietary libraries your market is going to be limited because OSs will distribute them and it will be hard to keep up when customers are fixing their own problems.
I don't see how. Think about the 100 (or 10 000, if you're doing webdev) dependencies your product uses. Most of those could be a licensed product, creating a cottage industry of small vendors making a living from developing specialized libraries. This thing is real in some areas, e.g. industrial software, where there are e.g. protocols that are too complex and boring for Open Source community to care about supporting in full. But it's something impossible in general, because popularity of open source simply prevents this kind of market from forming.
Now, to be clear: I don't have a strong opinion on whether this is good or bad. Still trying to fully understand that one. But what I know for sure is that open source is a huge disruption to how the market would've worked otherwise.
> What killed the shrink-wrapped market was first piracy
I'm not convinced about that. Maybe video games had a problem, but money in software in general was in B2B, not B2C, and there the piracy was effectively mitigated by the legal system. In fact, both Microsoft and Adobe used piracy as opportunity because of that - kids would grow up using pirated copies of professional software, and then as adults, their companies and their employers would have to buy the properly licensed versions of that same software, because that's the only thing anyone has experience in using.
> The SAAS model also has the benefit of aligning value delivery with outlays temporally. No more wait a year before shipping: instead get quick iteration with an ongoing revenue stream. You can recover from missteps in a way that the old model could not.
SaaS has some benefits, but they tend to be single-sided, unless the customer and the vendor are comparable in power, which usually isn't the case. So while e.g. IBM or Microsoft can force Google or Adobe to behave, my small business will be taken advantage of by large SaaS vendors.
Computers always allowed you to copy code for free and any new concept that took six months to be made up, can be duplicated for free in one second.
The real problem is that you have to ship code that can be disassembled and read by another human being, to sell software. This fact annihlates any incentive and control an author-of-software has over their conceptual labor.
What we need is a method to sell a binary (and source-code) that are completely free of human-perceivable information AND authorized against a purchase server. Identify the code author or not, both are fine, what matters is the conceptual labor is protected.
That's it. We do that and it becomes viable to do hard mental work for a long time, and take risks on bold moves. Make the concept work and sell the baked end result without giving away the recipe.
Every other industry keeps the means of production to themselves.
But for some awful reason, programmers are expected/required to ship the means of production, the understanding of the code and the concepts of the code AND be ready to answer anything, in a relationship with the purchaser.
The balance of effort between software developers and the benefit everyone else gets from them, is completely messed up.
That sounds impossible in principle, not without taking away ownership of the machine from the user. I guess TPM + homomorphic encryption might allow this one day, but that doesn't feel like a win for society.
> But for some awful reason, programmers are expected/required to ship the means of production
Pedantic, perhaps, but I wouldn't classify code as "means of production". Dev tools and supporting tooling, maybe, which no one is required to ship.
I sort of agree with you're saying overall - you're pointing out the fundamental issue, open source is just something enabled by it. I focused on open source because, arguably, this reality of "messed up balance" was still manageable through the legal system, and it's the FLOSS becoming a cultural phenomenon in the industry that broke this.
Generally it does not:
Microsoft Windows EULA states:
"Disclaimer. Neither Microsoft, nor the device manufacturer or installer, gives any other express warranties, guarantees, or conditions. Microsoft and the device manufacturer and installer exclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement. If your local law does not allow the exclusion of implied warranties, then any implied warranties, guarantees, or conditions last only during the term of the limited warranty and are limited as much as your local law allows. If your local law requires a longer limited warranty term, despite this agreement, then that longer term will apply, but you can recover only the remedies this agreement allows."
Source: https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/U...
Oracle EULA states:
"Disclaimer of Warranties; Limitation of Liability THE PROGRAMS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ORACLE FURTHER DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT."
Source: https://www.oracle.com/downloads/licenses/standard-license.h...
And that's a real damn shame, too. If only we had actual Engineering certifications for software engineers.
Things would be a lot more expensive... but perhaps they'd be a lot more consumer-friendly too.
See Canada: Software Engineers are called Software Developers there, problem solved.
(Now, there might be an argument you could make that, if software engineers had actual certifications, they would have the leverage to push back against Microsoft management and say "no, we're not going to ship that". But I'm pretty sure that wouldn't work, at least not at this stage of the game. Microsoft would just find coders in India or the Philippines or somewhere to implement it where there are no such professional regulations. No, when a company the size of Microsoft does something like that, the problem is not with the individual contributors.)
An ethics course is no panacea. But what I learned in ethics has been far more useful in my career than a lot of my hard CS subjects.
I mean, you don’t sign a 20 page contract when you visit a restaurant saying you agree not to sue them if you get food poisoning. Or sign something saying you take responsibility if you die in a plane crash, or from a shoddy building collapsing on your head. Companies in all other areas of society are held responsible for foreseeable harm caused by the products they sell. EULAs make a mockery of that, and the law should void or ban them.
Software also suffers of untold expectations. Companies regularly spend as much time writing specs as developing the real software, and yet, imprecision still dominates the implementation.
In fact, in the US, if you get a licensed engineer to do an inspection or design job, they will also often include a list of disclaimers to avoid liability. You often have to negotiate the lack of said liability waiver in advance for a higher fee. Note, liability waivers don't protect from negilence, just all other scenarios.
That's a deep rabbit hole that leads to the Underdark (https://en.wikipedia.org/wiki/Underdark) of Enterprise Legal Agreements.
Only high-level legal wizards and magisters can go there and expect to understand anything and keep their sanity.
Not a lawyer, but I expect it comes down to "if you follow our guidelines and pay us enough we can make the following guarantees, but there are certain things that we simply do not cover."
This is exactly what a warranty is though.
Yes, but it is not for consumers. It is for big businesses that pay millions and have specific expectations. The more you are willing to pay to more you can get within specific limits.
Your original statement, "If you pay for software it generally comes with some warranty and guarantee of fitness for purpose." does not hold for consumers and only partially holds for enterprise customers.
It might be better stated: "If your business / entity / government has specific needs (e.g. compliance with legal or medical regulations, industry certifications, ISO requirements, auditing, etc.), has a large sack of money to pay, and a team of lawyers, then there are some software publishers who will sign contracts to guarantee you certain qualities about the software you license with them and perhaps some level of support of that software."
---
Limited Remedy. If Microsoft, or the device manufacturer or installer, breaches its limited warranty, it will, at its election, either: (i) repair or replace the software at no charge, or (ii) accept return of the software (or at its election the device on which the software was preinstalled) for a refund of the amount paid, if any.
---
Unless it's some sort of bespoke software with a detailed contract (the details of which aren't available), I don't believe that's true.
Every single software license (as well as websites and other services) I've ever read (over the past 30 years or so) has had some similar disclaimer.
Would you provide an example that doesn't follow that pattern?
What needs to be done in commercial software, as is done in all other industries and in existing safety-critical software deployments, is segregating use cases by criticality and requiring deployments reach and guarantee the necessary quality level for that criticality class. It is the job and liability of the deployer to guarantee the requirements are met. They may push these requirements down to their suppliers, but it is the deployer that is ultimately responsible.
This is why Home Depot is not required to only sell aircraft-grade rivets. It is the airplane manufacturer’s job to source adequate components, not the job of all component suppliers to guarantee their components are fit for all possible purposes.
Under this model you can release any software you want. It is the manufacturer using the software that bears the burden of proving it is adequate. Or, if the software maker want to voluntarily take on extra burden, the software maker can verify and certify that the product is adequate for whatever purpose they wish to support.
Quality where it is necessary, and flexibility where it is not.
People lost their shit over the 737MAX. Boeing lost a ton of money and credibility. It made everyone realize that strong regulations need to be maintained and how it's a bad idea to allow manufactures to review their own product. It's also likely to result in even more regulations and a executives at Boeing being criminally tried.
Regulations are incredibly effective, but you can't go soft because they are working. Regulators have to be ever vigilant and politicians who push for softening of regulations need to be voted out of office. We are finally starting to see that conspiracies to skirt regulations constitute criminal behavior by senior company leadership, this is a good thing for the public.
I'm not sure I really see a distinction between that and a hardline tough on crime position. Not all laws/regulations are good and even an ensemble of individually good rules could be problematic in aggregate. Though in the current political climate, I would tend to agree that those pushing for reducing regulation are mostly not doing so as part of a well-intentioned effort to reduce adverse effects of regulation for the public good.
So now you want to regulate in security, for a device that was never meant to be secure in the first place?!
This security business is a racket. If you wanted computers to be secure, you would have designed and sold ASICs from day one.
You can't regulate software without also regulating the hardware.
The UK locks down privacy laws and now you guys want to "secure and regulate software".
The internet, no more. Offline is the only way to program, and keep software in-house.
As an example Red Hat OpenShift added support for crun(https://github.com/containers/crun) this year(https://cloud.redhat.com/blog/whats-new-in-red-hat-openshift...), which is written in C as an alternative to runc, which is written in Go(https://github.com/opencontainers/runc)...
Specifically, OpenShift is supported on both POWER and IBM Z in addition to x86 and ARM.
But probably the main reason is that the project started in 2018, when Rust didn't have nearly as much momentum.
> OpenShift Container Platform uses CRI-O as the container engine and runC or crun as the container runtime. ->The default container runtime is runC.<- Both container runtimes adhere to the Open Container Initiative (OCI) runtime specifications.
As for Rust-written runtimes, there is another project in the Containers GitHub namespace called youki[1] that is attempting to do just that.
[0]: https://docs.openshift.com/container-platform/4.13/post_inst...
[1]: https://github.com/containers/youki
(looking for real-world anecdotes, not preexisting assumptions)
(Anyway, happy coding…week…or whatever.)
That being said, I'm still puzzled why email programs don't differentiate mail from your bank vs. mail from yourbank.phishing.site.
It was never a good idea to use a performance-oriented language for software that should have had its highest priority as security, and it will be remembered in the long tail of history in the same way that asbestos is: a hazardous material that took us a long time to rid ourselves of.
You sound like you're using the uncomfortableness as evidence of the truthfulness. Logical inference doesn't work like that.
Particularly his wording: dereliction of duty
https://youtu.be/Gh79wcGJdTg?si=sDUart8rXTCzERA_
There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.
[0] https://www.red-lang.org/
When they totally could be doing `go get sources.redhat.com...`
If someone works around that on a developer machine, it shouldn't matter, because release builds should still come from an automated system, right?
You say "just 8 years ago" but another way of phrasing that would be "only 4 months after Rust went 1.0". And that's the first release, which means work probably started before Rust went 1.0
>Red Hat is one of the companies that also has a strange C addiction for almost anything.
This is kinda true and I wish it was different, but most of the examples people bring up are ones like the one you brought up. Rust wasn't a "safe choice" at the time they were started.
There's other factors too, like needing to support POWER and Z architectures. If you have a lot of such products written in C, and you have a GCC toolchain team in-house, that's not so difficult. If you have a lot of such products written in Rust, and your LLVM toolchain team is much smaller and the compiler itself less mature on those platforms, it's a bit more challenging. And then the whole issue of dynamic vs. static linking, where there's a ton of organizational inertia in favor of the former.
All that said I think the list of valid excuses is increasingly small nowadays.
Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people choose to use them), not from the demand side (shame people into adopting Rust).
I think there is a significant portion of developers that want to leave C++ for a better language, but for different reasons may not be satisfied with Rust or Go, so they just stay on C++.
1000 C++ servers vs. 100,000 Python servers is a big reason to avoid Python.
To keep iPhone apps responsive, they saw problems with apps using GC.
They removed tracing GC from Objective-C, because it was a failure when dealing with C semantics.
Automating retain/release calls was a much easier and safer approach, hence plan B.
In any case, reference counting is a GC algorithm.
Another may be that it simplifies the runtime for system code such as kernels and device drivers.
But people do use GC on their phones, insofar as they like to use web browsers.
.NET interop with COM is a good example of how mixing a tracing GC with a reference counted runtime requires an higher engineering budget that Swift team most likely wasn't willing to spend resources on.
It has been proven multiple times that reference counting is slower and has performance issues when dealing with large graphs, and also stop-the-world issues when cascade deletions occur.
If only pro-RC folks would bother to read CS papers and benchmarks.
I can think of two reasons for people not moving: 1. inertia, aka "not going out of comfort zone to learn new things" ("learning" includes understanding why things are different, not merely knowing they are). This won't be addressed by another new language that people will also need to learn.
2. Existing codebases won't magically turn from C++ to Rust. Legacy is actually a good reason to still be using C++ today, but another language also won't address this, as the fundamental issue is you can't change the existing code to be safer without effort.
In both cases, time and effort on the language best positioned to replace C++ (Rust) will alleviate these issues. In particular this effort could be spent to fully close the feature gap with C++ (specialization, more expressive consts, ...) and improving Rust/C++ interoperability.
No need to "shame" people, but finding a way to replace C++ use by Rust use is how we will solve the problem.
All of those are currently at the research project stage, so Rust is really the only game in town to replace C++ at the moment.
This has largely happened already. Java is in fact a memory safe language which has replaced a whole lot of C++ code since the late 1990s. It's only in a few highly performance-oriented areas where the debate ("should we be replacing C++ with a memory safe language?") is still undecided.
CVE-2017-5638 was famously exploited to gain access to Equifax's network and cause a massive data breach. Log4Shell is continuing to cause problems in all kinds of networks due to the extremely widespread use of the Log4j library. Java is definitely an upgrade over C/C++, but there are definitely still security risks.
C++ continues to be popular because it's a powerful language and can easily integrate with a ton of libraries, and most people don't care much about security.
My gut feeling is that a different language with less friction will gain more traction.
But hardly any languages integrate with C++ very well. Have you ever used SWIG? (Shudder...)
I do agree it would be nice if it could. The cxx crate is ok but we could do a lot more.
Maybe something like SWIG but based on LLVM so it actually works properly.
You should be able to run any program you want, no matter who wrote it, nor the language used, safely. If you can't do that, your operating system sucks. Security is the operating system's job.
Just because we're collectively hotwiring everything to the computing grid, and just telling programmers, admins and users to be more careful, doesn't mean its a sane way to live.
To cope with our current insane situation, we've all discovered coping mechanisms, like putting things in VMs, Containers, using Sandboxes, etc... none of them are as effective as specifying at runtime exactly what side effects are allowed. The user can do it using powerboxes, the admin can do it in a batch file.
We can have easy to use, secure, general purpose computing, but at present, the Overton window is too far away for most people to see it as even possible.
I supposed it was like that with the electric grid at some point, too.
That’s just flat out not true. It’s jot possible for an operating system to be perfectly secure without unduly locking down the capabilities of applications.
Considering the enormous feature-set of 1981's Intel iAPX 432, perhaps in 2023+ it should be the job of the hardware instead.
Lisp Machine 2.0?
It will take generations, doesn't make it impossible, and you already see this change happening in mobile OSes like Android, where C and C++ are frowned upon for regular app development other than games.
Transportation. Motor vehicles are a huge chunk of the market despite the existence of less deadly alternatives.
https://www.redox-os.org/
https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html
https://news.ycombinator.com/item?id=26554539
Which isn't to say we can't take some learnings from the idea, just that it isn't simply a matter of money.
Most web services do this in the network level with load balancers that forward only a single port to the service VM that is otherwise behind NAT to prevent any access to any other program in the VM that is left listening on a port. You can extend this concept to the input and output processing of the service.
so many critical exploits use the same characters and lengths as intended inputs. Also, if firewalls were a replacement for secure code, no one would be talking about memory safety.
https://github.com/stong/how-to-exploit-a-double-free
The analogy to firewalls is that you would specify the exact condition of the input for it to forward to the actual program. For example, if your endpoint receives json, you would validate the json and check each field value for valid range, ie min max number of characters and what those character values could be for each field. Just like a firewall limits who can talk to who in way.
In the same time I am teaching my daughter how to do buffer overflows with a board game I just released: https://punkx.org/overflow/
I think memory unsafety is what makes computers fun, ever since I read phrack 49/14 it made me see programs in a different light and actually enjoy programming way more.
In the same time I would like to not have zero click zero day exploits on my iOS phone where I cant control at all what code is executed.
The DoD funded Ada which curiously is not mentioned here.
The above sentence is also strange because it is not "the market" that "tolerates" dangers to the user (customer). It is the legislature that tolerates it. If it's legal and triggers no civil liability for a manufacturer to "sell" (a license to) a product that is dangerous, then why would it refrain from doing so. And further what if the customer has no viable alternative to "purchasing" (a license to) the dangerous product.
Sell and purchase are in quotes in the event we are referring to either (a) so-called "tech" companies that derive necessary revenue not from software (license) sales but from advertising services sales and/or (b) software companies that sell licenses to OEMs (customers) rather than directly to users. In neither case does the user actually purchase the software (license). In these cases, even if we assume, correctly or incorrectly, that users are "the market", it is arguable they have no meaningful choice of viable alternatives. This might explain why they "tolerate" dangerous software. If we assume, correctly or incorrectly, that advertisers or OEMs are "the market" then, as above, they "tolerate" dangerous software because legislatures have not made this illegal or a source of civil liability.