51–60 of 80 posts
Does anyone have any info on this tool? I'm intrigued.
How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.
There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed). BoringSSL[1] is Google's attempt. [0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/
Earlier quoted context omitted.
Gosh, to fix such a problem we'd almost need some kind of machine that can run a different program than its current one. Perhaps with evidence of that as a possibility, we could use a good crypto library instead, eg. https://github.com/jedisct1/libsodium
libsodium is not an OpenSSL replacement and doesn't want to be. It's a cryptographic primitive library and generally doesn't implement cryptographic protocols (eg. TLS, X.509, CMS, CRLs, OCSP, ...).
Earlier quoted context omitted.
There is also the F* version, which can be made to target C via their KreMlin compiler. https://project-everest.github.io/ https://fstarlang.github.io/general/2016/09/30/introducing-k... Presented at this year's ICFP conference. https://www.youtube.com/watch?v=sP7PRHn9iEA
I reposted your link on Lobste.rs. I noted that COGENT already was doing verified functional with certified translation to C or assembly. Also that F star to C seems to be Microsoft and INRIA's route. So, at least two projects are making it much easier to verify algorithms or protocols in functional way with C code resulting. The other thing I noted is that most code meant for verification is designed to be easy for…
Earlier quoted context omitted.
I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries a…
Rust guarantees safety under certain conditions. That's it. It doesn't guarantee good design, bug free code, or code that never behaves badly. This is the kind of gratuitous maligning of code written in other languages that some Rust fans engage in that I find off-putting. Rust isn't The Solution To All Our Problems.
Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen.
Also most of the C tools that help reduce memory corruption, if not hardware assisted like on SPARC v9 and Skylake, are mostly limited to having all source code available.
It feels like moving from Assembly to an higher level programming language.
Earlier quoted context omitted.
It's yet another in a long line of bugs due to C. It is, of course, possible to have bugs in every language. Even in a theoretical bug-free language it'd be possible to flawlessly implement a buggy algorithm or standard. But some languages make some sorts of bug difficult, and others make them easy: C is in the latter group. I suspect that assembler for the primitives and a good, sane high-level language (Haskell? Ca…
I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of th…
https://crates.io/crates/rustls is a TLS library built on top of ring.
Earlier quoted context omitted.
I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of th…
See https://crates.io/crates/ring , which is a fork of boringSSL, porting the C over to Rust. Endgame is 100% Rust and asm. https://crates.io/crates/rustls is a TLS library built on top of ring .
Edit: Re "just know they exist" (meaning libraries) in the answer: That's why I started the topic, the people who use only C wouldn't have chance to try the library unless the people who know enough Rust give something explicit that works and can be actually tested in linkability, functionality and speed.
Earlier quoted context omitted.
I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of th…
Already done in Ocaml for projects willing to use something other than OpenSSL: https://github.com/mirleft/ocaml-tls It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers.…
Earlier quoted context omitted.
Already done in Ocaml for projects willing to use something other than OpenSSL: https://github.com/mirleft/ocaml-tls It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers.…
Thanks, but which of those can be simply taken as the library linked to C code and called from the C code, and so that it doesn't depend on GC? Because as long as that step doesn't exist, it can't be used as the possible substitution for the current libraries?
Earlier quoted context omitted.
Thanks, but which of those can be simply taken as the library linked to C code and called from the C code, and so that it doesn't depend on GC? Because as long as that step doesn't exist, it can't be used as the possible substitution for the current libraries?
Ocaml is only one that uses GC IIRC. Others produce C.
Edit: also thanks for explaining the nature of the solutions you mention ("custom jobs").