A proactive approach to more secure code | Hacker News Reader

A proactive approach to more secure code

msrc-blog.microsoft.com

132 pointspjmlp28 comments

They are claiming up to 70% of the vulnerabilities can be avoided in a language like rust, I think a good chunk of the other 30% can be avoided using a language with a type system like rust's. I'm continually amazed at how much an expressive type system can help minimize bugs

This. Going from JS to strict TS eliminated a large portion of bugs, that with a strict state flow (redux in this case) it eliminated 95% of the bugs we encountered in the past.

We've also seen dramatic changes in the amount of defects found after migrating most of an app to TypeScript in strict mode.

Typescript makes writing large codebases in js actually possible. But it's still missing a few things and there's not much they can do about it. Pattern matching, and real support for sum types (not just having a 'type' field w/ a string) would be at the top of my list I think. Working with type parameters can also get a bit unweidly, and bounding them with the 'extends' keyword is a pain in the ass. IMO of course.

Is this an influential body inside MS? Sounds like good news for the Rust community that a team like this recommends that a bigco like MS explores Rust.

MS is already exploring Rust via Azure IoT Edge, VSCode search engine, Actix, Firefox for HoloLens.

So it is positive that security group is also pushing for it, alongside .NET and Core Guidelines for C++.

Now how much politic weight they are able to carry, remains an open question. If WinDev was more sympathetic towards DevDiv probably Longhorn would have actually happened, as proven by Singularity and Midori.

> probably Longhorn would have actually happened

Longhorn would have happened if it were feasible and AFAIK it was one of the reasons for why Windows Vista took so long.

It would be feasible if WinDev had not sabotaged the work, as it became later visible with moving Longhorn design into COM for Vista, followed up by WinRT, with a .NET toolchain designed by WinDev, partially incompatible with standard .NET features. Sinosfky wasn't that keen in having .NET take the lead.

Now after Midori, and the way things turned out for UWP, we are coming back full circle with .NET 5, XAML Islands and WinUI.

Singularity and Midori relied on GC for memory safety, and that was a huge problem for Longhorn/Vista because it was very difficult to write code that would work reliably when memory is critically low.

Rust is a completely different story. Sure, Rust's standard library treats OOM is fatal, which is the right thing for almost all application code, but it's not difficult to create Rust libraries that treat OOM as a recoverable error, or that don't allocate at all.

If the Singularity group had invented Rust instead of Sing# things might have turned out differently.

Yet according to MSR Midori had no issues powering a portion of Bing in production.

Multiple OSes have been written in GC enabled system languages.

Having a GC doesn't mean all memory is required to be GC allocated on the heap, usually the same mechanisms of a language like C++ are also available, e.g. Modula-3, System C#, D and so forth.

Joe Duffy clearly states in one of his Midori talks that WinDev did not believe in Midori, even with it running in front of them.

Agreed. Mozilla and Cloudflare and Dropbox are great, but given the language's ambitions it would be a huge benefit to have real commitment from one of the big five.

For those who wants to see some rust in action, here are some OSS tool written in Rust and very efficient:

RipGrep[0]: Replace Grep and it is blazing fast

bat[1]: Replace cat with better display and colours

exa[2]: Replace ls with many more options

[0]: https://github.com/BurntSushi/ripgrep

[1]: https://github.com/sharkdp/bat

[2]: https://github.com/ogham/exa

I do not have any affiliation with them, I just use them a lot

Edit: formatting

So 70% of the vulnerabilities are still caused by lack of memory-safety, and that doesn't even account for all the defects that don't end up in a vulnerability. Imagine how much more safety and correctness there would be, if not only those 70% didn't exist, but no time had to be spent to fix them and rather concentrate onto avoiding the other 30%.

Morris worm is 30 years old now, what allowed it is still pretty much 2019 regular C code.

This would be a massive boost to the rust community as a whole as many would have a look at it!

Replacing a safe language, C#, with an unsafer but faster language, Rust, is of course fine, but then they shouldn't label it wrong.

This isn't an advisory, it's just a blog post. We're meant not to editorialize titles, and this one was a doozy; the appropriate title is "A proactive approach to more secure code".

I've noticed that happening a lot lately. It's frustrating because the blog post is interesting on its own merits and doesn't need to have a click bait title inserted.

See the recent front-page post about "England selects new face of fifty-pound bill" or something of the sort. The title of the linked BBC article included that Alan Turing had been chosen, yet the poster chose to make it click-bait.

Maybe my lack of English skills, just provided the title that made sense to me, as 1:1 mapping to the title seemed not fully describing their intention.

Yeah, you're specifically not supposed to do that here.

https://hn.algolia.com/?query=author:dang%20title%20editoria...

Because "advisory" has a specific connotation, the title you provided managed to be a lot more misleading than the post's original title.

Well that should be visible on the submission link page.

In any case, I cannot edit the title now.

I submitted with the original title and it never even hit the front page: https://news.ycombinator.com/item?id=20453837

It’s unfortunate how effective editorializing is.

In other words, Windows is about to become slower.

Depends on which memory safe language they use and how (plus this blog post isn't by the Windows team or about Windows specifically). The biggest thing that slows Windows is lock contention, back-compat, and abstraction layers. Those problems all remain regardless of language choice.

Taking what's probably a joke too seriously for a moment, I don't think that follows at all. This is a research group within Microsoft doing exploratory work, so it shouldn't affect Windows at all. Further, they say they are "starting with Rust", which is not a whole lot slower than C++ (and you can always dip down into a different language for extremely performance sensitive parts).

Windows' slowness is almost all attributable to process startup time and a lot of modern apps being based on Electron, Chrome, JavaScript, and other very process-happy environments. Writing applications in Rust is not going to change Windows' process startup system.

First step was to keep C support around for legacy reasons and push C++ for systems level programming.

I did not notice any slowdown on a 10 years old laptop running the latest release from Windows 10, on the contrary it is quite snappy.

Reply on news.ycombinator.com