Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

Post reply on HN
Print view View original

191–200 of 386 posts

Re: The Insecurity Industry

#191

Post by pjmlp »

lionkor wrote: post #181
FractalHQ wrote: post #148

Earlier quoted context omitted.

Can’t unsafe Rust (when properly isolated) exist within a larger codebase that, as a whole, can still be considered safe?

The same way you can write safe modern C++ and only use unsafe features of the language when its necessary and isolated, but thats also considered unsafe, so Rust should be, too

My experience with trying that in Visual C++, alongside the C++ Core Guidelines and "borrow checker" static analysers, is that there is what we wish to happen, and how the code actually looks like in reality.

Re: The Insecurity Industry

#192

Post by roca »

trasz wrote: post #165
roca wrote: post #124

Earlier quoted context omitted.

That paper has many problems. For example: > There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C To be clear, those "alternative implementations" do not exist , and no-one actually working on C compilers or tools to make C code safer has been able to produce one, or even come up with a credible plan for producing one.

Of course they exist, see eg CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

CHERI is far more than just an "alternative implementation of C". It includes a completely different hardware platform and replacing all your hardware can hardly be considered "cheap".

Re: The Insecurity Industry

#193

Post by pjmlp »

conradev wrote: post #134
nine_k wrote: post #126

Earlier quoted context omitted.

Funny that you ask: Linux kernel rather actively embraces experimental code written in Rust. And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4. Google is working on Fuchsia as a new phone / chromebook OS, and it's very much focused on bulletproof security.

While Fuschsia's microkernel architecture has a lot of security benefits, the microkernel (Zircon) is still written in C++

For the time being yes.

They are now starting to rewrite OS components in Rust, and I wouldn't be surprised if that happens to Zircon as well, it stared as a C anyway, and thus already suffered one rewrite.

Re: The Insecurity Industry

#194

Post by Ieghaehia9 »

nine_k wrote: post #126
yashap wrote: post #122

Earlier quoted context omitted.

Would you refuse to use Postgres, the Linux kernel or SQLite because they’re all written in C? Certainly C and C++ have more footguns than many other languages, but highly insecure as well as highly secure software gets written in all languages. I think coming up with better/easier avenues for digital-security-breach related lawsuits and fines is a better idea than banning specific languages.

Funny that you ask: Linux kernel rather actively embraces experimental code written in Rust. And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4. Google is working on Fuchsia as a new phone / chromebook OS, and it's very much focused on bulletproof security.

> And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4.

One of seL4's points is that security can still be fast, no?

From https://docs.sel4.systems/projects/sel4/frequently-asked-que...

>To the best of our knowledge, seL4 is the world’s fastest microkernel on the supported processors, in terms of the usual ping-pong metric: the cost of a cross-address-space message-passing (IPC) operation.

Re: The Insecurity Industry

#195

Post by pstch »

sydthrowaway wrote: post #74
throwmeawayya wrote: post #55

Earlier quoted context omitted.

Did the US government explicitly deny him a fair trail?

Look at the dirty tricks they employed with Assange. Snowden’s paranoia has been vindicated.

It's not even paranoia. He wants to present reasons of his actions, and the judicial authorities won't allow that, and are not even really hiding it.

Re: The Insecurity Industry

#196

Post by pjmlp »

DoingIsLearning wrote: post #158

It feels like we've gone full circle back to 1980 when the US Defense comissioned a 'safe' embedded language. Jean Ichbiah's team won this contract with the language 'Green' in 1979. They subsequently went on to further develop this and standardize it in what was then the Ada 83 language standard. The more I think about the more it feels that Ada just came about to solve the right problem but at the wrong time.

Unisys still sells Burroughs to customers that care about top level security.

https://en.wikipedia.org/wiki/Burroughs_large_systems

ESPOL/NEWP were the very first system programming languages to have UNSAFE code blocks, 10 years before C was even an idea.

Before that there was JOVIAL as well, https://en.wikipedia.org/wiki/JOVIAL

Re: The Insecurity Industry

#197

Post by tester34 »

dmoy wrote: post #18
o8r3oFTZPE wrote: post #11

"For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product." That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet. Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "…

Most of the people I went to Uni with ended up in fields where the companies are liable for bad stuff, to a certain degree. It does exist. However: * you get paid a lot less * the companies and industries move very slowly * you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things I mean like Real Engineering fields. What we do in so…

>I mean like Real Engineering fields. What we do in software is not real engineering, not even close. That has pros and cons.

"Real Engineering" has definition and it fits SE, doesn't it?

Computer industry iterated and managed to reach the point where we can move really fast and do not break computers with bad code. That's result of thousands of hours of engineering effort of previous generations.

>Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings. The discipline of engineering encompasses a broad range of more specialized fields of engineering, each with a more specific emphasis on particular areas of applied mathematics, applied science, and types of application. See glossary of engineering.

Re: The Insecurity Industry

#198

Post by pjmlp »

dxuh wrote: post #177

Everyone in these comments mentions C and C++ as a single word, which frankly has nothing to do with reality. C++ is a FAR safer language than C, if you wish to use it properly (which many don't). I write C++ full time at work and I also use it a lot in my free time and I rarely if ever have out of bounds accesses, use after free or any of these bullshit errors. If you use modern C++ and AdressSanitizer and don't do…

Because even companies like Microsoft and Google don't write modern C++, you can easily validate this on their public repositories.

See how much modern C++ you will find in AOSP and NDK, WinUI or XBox code samples.

Modern C++ exists only at talks in CppCon, C++Now.

Re: The Insecurity Industry

#199

Post by kragen »

pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

If this happens, it will be the end of open source and the indie web. Only large companies with large legal departments and serious liability insurance, and anonymous underground hackers, will be able to afford to make software public for commercial use or run a website.

Re: The Insecurity Industry

#200

Post by pjmlp »

roca wrote: post #125
lu4p wrote: post #29

Earlier quoted context omitted.

True, but still memory safe, also Go has a race detector included which is really easy to use https://blog.golang.org/race-detector

No, Go is not memory safe for concurrent code. Race detection is good but can't eliminate races altogether.

Same applies to Rust as well actually.

Its type system only prevents data races for in-memory data structures, on the same OS process.

There are plenty of other concurrency races.

Post reply on HN