Another piece comes to .NET Core: Microsoft will keep the runtime patched automatically

Microsoft will add the .NET Core and .NET 5.0 runtimes to the update service built into Windows - but enterprises must opt in, and applications have to be deployed using a shared runtime for this to be effective. These .NET runtimes though, unlike the older .NET Framework, are not treated as system or operating system updates …

[Mike 137]

"Microsoft will keep the runtime patched automatically"

It would be really nice if they could get it right instead of merely posting fixes for their cock-ups if you choose to sign up for them. Same for all vendors really.

No civil engineering business would survive if they had to keep sending in workmen to fix faulty electrics, plumbing, flooring, roofing etc. for the entire life of an office complex.

It's a myth that it's intrinsically impossible to create bug free software. it just needs a different approach to development (an engineering approach). The product would be more expensive to create and therefore also at "point of sale", but its entire life cycle cost to the user would be much lower and it would be vastly safer to use.

"Cyber security" primarily consists of protecting against abuse of typically rather elementary software bugs that shouldn't have been there in the first place.

[John Miles]

Re: It's a myth that it's intrinsically impossible to create bug free software

I am an Electronics Engineer who switched to software - however I'd disagree, I'd say it is impossible to build any complex software system which is bug free within a useful/reasonable time period. I am not even sure with enough time you could make it bug free due to complexity. Even if the system doesn't hit bugs under normal circumstances there will likely be conditions that can be exploited by the black hats as engineers/developers have a logical approach which can blind them to potential attacks vectors.

You can however build highly reliable systems and resilient with the right level of discipline, which rarely hit the bugs and I don't think it actually takes any more resources if you start out doing it correctly. However a lot of managers don't understand this and it takes time and experience for a developers to get into a position they have the right skills to apply the discipline needed, which they'll never get if they spend lots of time stuck on doing it by yesterday without people with the skills to guide them

[karlkarl]

Re: It's a myth that it's intrinsically impossible to create bug free software

"however I'd disagree, I'd say it is impossible to build any complex software system which is bug free within a useful/reasonable time period"

Absolutely. Why is why the correct solution is to generally simplify. Which unfortunately is something that Microsoft (and most consumer software) is unable to do so. Instead they just add layers upon layers of extra crap on top.

There really is something to the UNIX approach. That is why it keeps coming back like an old friend (or itch rash depending on who you are talking to) :)

[iGNgnorr]

Re: It's a myth that it's intrinsically impossible to create bug free software

"Why is why the correct solution is to generally simplify."

I worked for some time under a manager who kept wanting to *add* simplicity. She didn't seem able to understand that adding anything is the exact opposite of simplicity. You can just guess what the product was like both before and after simplicity was added.

[Kristian Walsh]

Re: It's a myth that it's intrinsically impossible to create bug free software

I agree that the Unix approach is a good one. However, the dominant Unix-derived OS in use today, Linux, doesn't really follow it anymore. The Linux-only tools like ip are a mess of sub-commands and special cases, each producing pre-formatted output that's unsuited to processing by other tools further down a pipeline.

Ironically, it's Microsoft who have remained closest to the old Unix idea, with PowerShell. Because PowerShell commands output machine-parseable objects, not pre-cooked text, you can do exactly the sort of chaining and division of responsibility that the K&R Unix tools let you do, even with complex output types. I can't get along with PowerShell for other reasons, mainly to do with it not providing the Unix core commands, but this is one area where it really shines.

It would be good for something similar to be implemented by the Linux system management tools (even if it has to be via something crap like JSON as an intermediary), but the problem isn't a technical one, but rather a political one of getting all the maintainers to agree to a standard way of interchanging information, and that's playing to the biggest weakness of the FOSS model.

[Jon 37]

Re: "Microsoft will keep the runtime patched automatically"

People have tried to write security-bug-free software. They failed.

There was an effort to use formal mathematical verification. They even wrote a piece of software that way and proved that the software met the spec. Unfortunately, a few bits were too complex for their automated prover, so they manually proved them. One of those manual proofs had a mistake in it, which meant an exploitable security vulnerability in the code wasn't caught.

Even if your software is "bug free" when run on an ideal machine, real world hardware does not work the way people think it does. Caches, timing attacks, bugs in DRAM chips/controllers (RowHammer), wierd CPU optimizations that no-one really thought about (Meltdown/Spectre), bugs ("errata") in CPUs, all those things can introduce security vulnerabilities into the complete system.

Now, effectively bug-free software when not being maliciously attacked, and when running on simple (slow) hardware, that's possible but incredibly expensive and slow to write. The Space Shuttle software is probably a good example of that. I recall hearing that they could measure their documentation in pages-per-line-of-code. It was slow, methodical work. There were some known issues, e.g. they knew that they year rollover from 31 Dec to 1 Jan was buggy, but they knew about that and ensured all the space shuttles were on the ground at the end of each year. When they had to have the capability to fly during that time, they scheduled time to add the new software feature and did so, tested it and shipped it.

[Annihilator]

Re: "Microsoft will keep the runtime patched automatically"

"There were some known issues, e.g. they knew that they year rollover from 31 Dec to 1 Jan was buggy, but they knew about that and ensured all the space shuttles were on the ground at the end of each year"

An excellent example. Arguably, it was an invalidated assumption. From what I understand, they just never had a requirement for a space shuttle to be in orbit on new years eve, so never designed for it. So is it a defect? A missed requirement? A use case that was never catered for? Either way, it's never been clear to me when they actually recognised the consequence of this and made it an operating restriction instead. I'd highly doubt it was a known issue during STS-1.

[Annihilator]

Re: "Microsoft will keep the runtime patched automatically"

"No civil engineering business would survive if they had to keep sending in workmen to fix faulty electrics, plumbing, flooring, roofing etc. for the entire life of an office complex."

It's a mystery to me then, what I've been doing wrong all these years. I've had many a tradesperson in to service my boiler, fix faults that have emerged in electrics and also to repair a leaking roof once.

I also got really unlucky when I bought a new build house and had to get them back to fix a load of snags. Bizarre really, and thank goodness for the NHBC warranty that seemingly doesn't need to exist by your logic.

[needmorehare]

Re: "Microsoft will keep the runtime patched automatically"

Making high reliability software means gutting it of flexibility and in many cases profitability. Or to put it simply: Turning your powerful computer into a constrained appliance which does far less and has far less software available for it. Ignoring that side of things, the biggest weakness point in cyber security is no longer the software but human computer users.

Effective kernel/hypervisor mitigation techniques have eliminated entire classes of reliability exploitable bugs to the point where more and more reported vulnerabilities don’t “just work” on production systems any more and instead require many, many attempts to get around ASLR, SSP, CFG, VBS, mandatory integrity controls, system call restrictions and many other mitigations which security researchers disable as part of developing proof of concept exploits.

[Anonymous Coward]

.NET 5 doesn't run on Windows 7 ... unless ...

You pay M$ an annual fee which literally doubles every year.

So if you want to run .NET 5 code at no extra cost, you either install the StasiWare that is Windows 10, or else run Linux.

That's a really tough decision to make.

[DCdave]

Re: .NET 5 doesn't run on Windows 7 ... unless ...

Why would you expect a new framework to be supported on an already-deprecated OS?

[iGNgnorr]

Re: .NET 5 doesn't run on Windows 7 ... unless ...

Why is this a problem? If you are running Windows 7 you are either already paying for ESU, or you really shouldn't be developing any new software. I sure as heck wouldn't want to use any software built on a non-ESU W7 system.

[Anonymous Coward]

Re: you either install the StasiWare that is Windows 10, or else run Linux.

Or windows 8

[Anonymous Coward]

Auto-updates

No doubt they'll do a swift re-boot of the system when they update, regardless of whether you asked it to or not. And it'll only allow you to create "active hours" (but no longer than an 8 hour period).

From memory, you can fiddle about in group policy editor to modify this, which I had to do on the machine that I often leave running video encodes. Just give me the bloody option to "download and notify me to install" like you used to do.

Imagine I drove to the shops, went inside, came back out and discovered my car had buggered off to the garage for a service, then returned itself home. Just because I hadn't thought to click "pause updates" just in case, on every bloody journey. If Microsoft are involved in the self-driving car development, I want no part of it.

[Robert Grant]

Docker, people

Docker on K8s, separated from human contact by an API, squirrelled away somewhere on a server only CI (or an audited, temporarily-allowed human) can access. Minimise the chances that an exploit is anywhere near reachable and you're off to a good start.