Live data from Hacker News

Microsoft is creating a new Rust-based programming language for secure coding

zdnet.com

51–60 of 207 posts

Re: Microsoft is creating a new Rust-based programming language for secure coding

#52
post #20

Oh no, I bet it's gonna be a C# flavored Rust. None of Rust's terse syntax and functional influence. It's going to be full-blown Java-style OOP with plenty of Wnd handles to be thrown around. Yikes, I certainly hope I am not right.

Why not a F# flavored Rust? > plenty of Wnd handles to be thrown around That is not really a language issue, is it?

F# is as ugly as Rust

i hope they go for something more like Swift/Kotlin, much more modern and readable

Re: Microsoft is creating a new Rust-based programming language for secure coding

#53
post #39

Earlier quoted context omitted.

> Need to keep old insecure code around That's what process boundaries are for. (As a bonus, you get protection from any Spectre-like issues arising in the old code.)

Process boundaries don't protect against internal exploits, which is what most of the C and C++ exploits are all about. If you are able to force a process to change its behaviour, the process boundaries become useless.

Process boundaries specifically protect against these exploits.

Re: Microsoft is creating a new Rust-based programming language for secure coding

#55
post #39

Earlier quoted context omitted.

Process boundaries don't protect against internal exploits, which is what most of the C and C++ exploits are all about. If you are able to force a process to change its behaviour, the process boundaries become useless.

Process boundaries specifically protect against these exploits.

So how does a process boundary protect against Heartbleed?

Re: Microsoft is creating a new Rust-based programming language for secure coding

#56
post #55

Earlier quoted context omitted.

Process boundaries specifically protect against these exploits.

So how does a process boundary protect against Heartbleed?

Process boundaries help you when you start jumping through a ROP chain that spawns a shell because your process doesn't have access to things that it shouldn't, even when compromised. Calling Heartbleed an example of a process "changing its behavior" doesn't really make sense in the context of exploits that can cause arbitrary code execution.

Re: Microsoft is creating a new Rust-based programming language for secure coding

#57
post #49
post #42

Earlier quoted context omitted.

As a big proponent of F# it annoys me how much one still needs to fight "but M$" arguments if I point out a thing that F# does well. The same thing seems to happen when discussing Haskell with people who know just enough to recognise the influence MSR employees have on it. It almost makes me wonder how they/we can work around that sentiment now. Either hope for generational shift to eventually kill it, or perhaps hav…

“Fool me once, shame on you. Fool me twice, shame on me” I try to be objective as much as possible, but having witnessed almost all of Microsoft’s behavior through history, we have been fooled 100s if not 1000s of times. How many times do you let the fox back into the hen house? The only thing I think when I read recent “Microsoft is so great” comments is that the person is either too young to have any real knowledge…

Big companies are not autonomous and do not make their own decisions, individual people working at those companies do. I think it’s safe to say that anyone working there today has nothing to do with the time periods you’re referencing, so I don’t know why you would consider decades old issues to be relevant today.

Re: Microsoft is creating a new Rust-based programming language for secure coding

#58
post #49

Earlier quoted context omitted.

“Fool me once, shame on you. Fool me twice, shame on me” I try to be objective as much as possible, but having witnessed almost all of Microsoft’s behavior through history, we have been fooled 100s if not 1000s of times. How many times do you let the fox back into the hen house? The only thing I think when I read recent “Microsoft is so great” comments is that the person is either too young to have any real knowledge…

Big companies are not autonomous and do not make their own decisions, individual people working at those companies do. I think it’s safe to say that anyone working there today has nothing to do with the time periods you’re referencing, so I don’t know why you would consider decades old issues to be relevant today.

As part of the BSA, they still lobby for software patents today.

The OOXML Office format they used to continue pushing Office lock-in is very recent: https://wiki.documentfoundation.org/LibreOffice_OOXML

They tried their best to keep the list of their Android patents secret, so that they could not be worked around, and they abused their patent on the FAT filesystem as recently as 2012: https://www.howtogeek.com/183766/why-microsoft-makes-5-to-15...

They also still lobby against open standards: https://www.computerweekly.com/blog/Public-Sector-IT/Microso... https://www.theguardian.com/technology/2015/may/22/microsoft...

And lets not forget all the spying in Windows 10.

MS is as hostile as ever - it's a fantastic success of propaganda to make people think it's limited to "decades old issues".

Re: Microsoft is creating a new Rust-based programming language for secure coding

#60
post #55

Earlier quoted context omitted.

So how does a process boundary protect against Heartbleed?

Process boundaries help you when you start jumping through a ROP chain that spawns a shell because your process doesn't have access to things that it shouldn't, even when compromised. Calling Heartbleed an example of a process "changing its behavior" doesn't really make sense in the context of exploits that can cause arbitrary code execution.

So each one gives an example that suits their own sales pitch.
Post reply on HN