Live data from Hacker News

Qualys Security Advisory – LibreSSL

seclists.org

21–30 of 89 posts

Re: Qualys Security Advisory – LibreSSL

#22
post #7

Earlier quoted context omitted.

I know this opinion won't be popular, and I know encryption is a very complex topic, but ... TLS is simply vastly too complicated. How many of us here could write a TLS library even if we wanted to? So you end up with code so complex that even the smartest people can barely understand it, let alone debug it, and you get terrifyingly long CVE lists like for OpenSSL as a result. Compare that to a basic unencrypted HTTP…

Is it TLS specifically or X509 (both by itself and because it uses ASN.1)? I dimly remember X509 and ASN.1 being commonly criticised for their complexity, does TLS pile on additional complexity or just inherit it?

It's everything. ASN.1 is complex - people still make mistakes in the DER parsers as seen in this CVE. X509 is even more complex - it's not just ASN.1. It can be DER in DER in DER (parameters of certificate extensions). Have fun with that and memory ownership! (you have to recalculate and replace an object 2 levels above what you're actually changing) TLS is even worse, because it includes X509 as a format and then a ton more of actual processing logic, state machines, cryptography code, ...

I don't trust any implementation of it that uses unmanaged code. (yes, pretty much assuming everything based on openssl will be broken time and time again)

Re: Qualys Security Advisory – LibreSSL

#23
post #17
post #14

Earlier quoted context omitted.

Stop writing unmanaged code? This is just the same ol' story...

If you want interoperability you are kinda stuck with C. Nearly every Language can use C Libraries either directly or via FFI. While Rust can export functions the same way C does it you are in unmanaged land again then. With http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. The only limitation are the Data Types, you are restricted to those C knows.

Do you have more info about Pony's ability to expose C-compatible functions? I can't see anything in the docs (e.g. http://tutorial.ponylang.org/c-ffi/c-abi/ talks about going the other direction).

Also, FWIW, I don't think Rust should be considered unmanaged for these purposes: it bridges the divide between "managed" and "unmanaged" by bringing the memory safety of the former to a language that doesn't require a complicated runtime. So strictly speaking, yes, it's unmanaged, but it doesn't suffer the worst of the problems of existing unmanaged languages like C or C++.

Re: Qualys Security Advisory – LibreSSL

#24
post #17
post #14

Earlier quoted context omitted.

Stop writing unmanaged code? This is just the same ol' story...

If you want interoperability you are kinda stuck with C. Nearly every Language can use C Libraries either directly or via FFI. While Rust can export functions the same way C does it you are in unmanaged land again then. With http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. The only limitation are the Data Types, you are restricted to those C knows.

> With http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed.

You can do that with most "managed" languages. You can call Python, Haskell, Go or OCaml from C, pony isn't exactly special here.

One issue in all these cases is you're carrying a whole runtime with you, possibly one per library you're using, praying they don't conflict with one another[0] and limiting the portability of the whole[1]. You're also significantly increasing the cost of using the library in question as it now brings in megabytes of runtime along for the ride.

[0] with conflicting signal handling for instance

[1] if only because all those runtimes you're bringing in might be doing stuff like spawning their own threads and the like, so that needs to be available on the target platform

Re: Qualys Security Advisory – LibreSSL

#25
post #17
post #14

Earlier quoted context omitted.

Stop writing unmanaged code? This is just the same ol' story...

If you want interoperability you are kinda stuck with C. Nearly every Language can use C Libraries either directly or via FFI. While Rust can export functions the same way C does it you are in unmanaged land again then. With http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. The only limitation are the Data Types, you are restricted to those C knows.

Communicating via the C ABI between safe languages isn't inherently unsafe, as long as you drop pointers and other unsafe things from the passed structures. It becomes just another protocol that you handle in your safe language.

Re: Qualys Security Advisory – LibreSSL

#28

I have no knowledge of C, but reading their code I was surprised to see some gotos ... is this OK in C to use goto ?

It's a very common C error-handling pattern, essentially emulating RAII with forwards-only function-local goto statements. It's possible to do without, but that tends to yield much more deeply nested code (especially if it's complex) and possibly some amount of duplication.

See http://eli.thegreenplace.net/2009/04/27/using-goto-for-error... for a short rundown, or http://blog.regehr.org/archives/894 where regehr — who works specifically in correctness and verifiability — states:

> many people, including me, prefer the goto version

Post reply on HN