Yes. But you have to prove that your value proposition, doesn't lead to horrible failure down the line.
I.e. We need to make software fast, security be damned is not a valid argument.
No I do not. My software is done, it has run for decades on the Internet, making me money; For whatever you could mean by "horrible failure", what I am doing either doesn't lead to it, or it's clearly not that bad.
> ... is not a valid argument
We're not having an argument; You want to ask a question, I can give you an answer, but there's nothing here to argue:
I'm ``using a "memory unsafe"´´ language because I can write secure programs that run quickly with them, and I don't live in a Harrison Bergeron world.
This is about why you can't yet, and really doesn't have anything to do with me.
https://www2.deloitte.com/dl/en/pages/legal/articles/it-sich...
Eventually all countries will have similar laws.
Software company bares the cost of producing faulty software.
When it touches the bank, many companies will start considering alternatives.
In fact, this is what drove Microsoft et al to start finally embracing other stacks, the amount of money burned fixing exploits for free in OS updates.
Did you prove it mathematically?
Did you wrap it in Rust API and use miri to inspect for UB?
Did you ran it through ASAN, MSAN, STACK, etc?
All UB/platform-specific behavior has been accounted for?
So you ran fuzzers for days-weeks? What issues did it uncover?
Do your test coverage account for all cases and most input variations?
Or is this a case of ``I think I can write secure programs``. There is a light-year-wide trench between thinking and proving you can do something. And it still needs to break is not a guarantee.
It's easy to prove something isn't secure, one need only an example e.g. https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=hyper and so on and so on but there's nothing that's ever going to prove that something is secure from everything.
Thinking is the best anyone can do, and one of the most important things you can think about is where exactly you're going to draw the line.
No, it's not. That's why I am asking for clarification. By testing, proving programs, running fuzzers, running sanitizers, and various other tooling you reduce the chance of problems to an acceptable level. You can't be perfectly safe, but nothing doing anything isn't acceptable behavior in face of preventable risk.
> one need only an example e.g. https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=hyper
Sure, writing unsafe code is hard. And from what I see most of these issues relate to old versions of Rust having unsound issues that were fixed at later point.
> In the standard library in Rust before 1.52.0,
> In the standard library in Rust before 1.51.0,
> In the standard library in Rust before 1.19.0, ...
Basically by upgrading your Rust version, your code becomes less and less buggy over time, which is not something C can boast about (modern C++ is safer but still a far cry from what is achiveable in let's say Java).
