2 ms·
Since Go came up earlier, likely it is being contrasted with Go in this case, where Go has a fast and robust crypto library in the standard library. And yeah,
by jchw 3y ago
Since Go came up earlier, likely it is being contrasted with Go in this case, where Go has a fast and robust crypto library in the standard library.
And yeah, safety is clearly a continuum: hardware is not perfect, operating systems are not perfect, etc. However, being defeatist about this point is not really the way to go. We should aim to replace less safe things, especially in safety-critical parts of applications like the cryptographic operations and TLS implementations, with safer things. That's definitely why in the Rust ecosystem there's been a huge emphasis on pushing rustls forward; it's a shame to put all of the work into making safe and robust software, only to have a giant OpenSSL or BoringSSL-shaped liability sitting in the same address space as your program. Battle testing alone has proven insufficient over and over and over and over, whereas statically verifying the absence of (at least some kinds of) flaws remains very promising still.
In practice I'm sure it's obvious that to make any application secure and/or robust it's going to take multiple layers of defense where ideally there is no single point of failure. But to make progress, you have to... you know, make progress. Programming languages, toolchains, and standard libraries can't stop your operating system from being insecure, but they do have the ability to not put less safe/verified things into your address space.
Maybe some day, all of these safe Go/Rust/Swift programs will have much more robust hardware and operating systems to run in that are, themselves, "verified" to have certain security assurances. For that to really be all that meaningful, though, the programs themselves have to actually be "safe".
And hopefully, even when standard library code can't be proven to be "safe" using the language's normal mechanisms, we can still prove it using heavier duty tools. But, it certainly isn't happening over night...
- trealira 3y ago> Maybe some day, all of these safe Go/Rust/Swift programs will have much more robust hardware and operating systems to run in that are, themselves, "verified" to have certain security assurances. For that to really be all that meaningful, though, the programs themselves have to actually be "safe". On some older operating systems, the system was safer in some ways. On the Genera operating system for Lisp machines, almost all code ran in a single address space, which was possible because Lisp is garbage collected and doesn't allow arbitrary reads and writes through arbitrary pointers. You could still write code in unsafe languages like C, but those programs did need their own address space, like in traditional OSes. On the Burroughs MCP operating system from 1961, it had a similar mechanism. It was written in the language NEWP, which had certain unsafe constructs marked, and if code used unsafe constructs, it had to be approved by the system administrator to be executed. https://en.wikipedia.org/wiki/Single_address_space_operating_system https://en.wikipedia.org/wiki/Single_address_space_operating... https://en.wikipedia.org/wiki/NEWP https://en.wikipedia.org/wiki/NEWP