5 ms·

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of

by kevan 11y ago

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.

orik 11y ago
is keeping score what we're interested in today? https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
- jldugger 11y ago
  "Secure connection failed"
- conradev 11y ago
  If you're looking for a chart, Wikipedia is keeping score: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
- xenophonf 11y ago
  Whether this bug affects the upstream project is a legitimate concern, I think. It would be like worrying that a vulnerability in OpenBSD affected NetBSD, too, especially if it was found relatively close to when OpenBSD forked.
Johnny_Brahms 11y ago
I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code. The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how anyone in their right mind writes C. If that is what is required to write safe C then I'm all for using another language. Edit: I do like how Zed Shaw writes C, but I have no idea if the software he wrote is safe...
- smt88 11y ago
  I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. I still think that will happen.
  - masklinn 11y ago
    > I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. Yes and no. No in that LibreSSL aims to be mostly drop-in compatible with OpenSSL (modulo deprecations/removals) and OpenSSL has a very complex API exposing lots of internal gunk to the user, so moving to a non-C implementation may not be possible at all. Yes because there's a related `libtls`[0] project which aims to define more abstracted API (with the reference implementation being done on top of libressl). As POC, tedu has/had an implementation of the API using golang's TLS stack[1], and noted that you could build the same on e.g. the OCaml/Mirage TLS stack[2]. If `libtls` fulfils its promises, it would become much easier to swap TLS stack and indeed move to non-C implementations. [0] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/tls_accept_fds.3?query=tls%5finit&sec=3 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/... HN discussion: https://news.ycombinator.com/item?id=8572029 https://news.ycombinator.com/item?id=8572029 (some comments may not apply anymore IIRC the discussion was the initial API which has been extended since) [1] http://www.tedunangst.com/flak/post/goreSSL http://www.tedunangst.com/flak/post/goreSSL [2] https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/introducing-ocaml-tls
- 0x01 11y ago
  If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution? Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely. I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!
peterwwillis 11y ago
laughs maniacally

by kevan 11y ago

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.

orik 11y ago

is keeping score what we're interested in today? https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html

jldugger 11y ago
"Secure connection failed"
conradev 11y ago
If you're looking for a chart, Wikipedia is keeping score: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
xenophonf 11y ago
Whether this bug affects the upstream project is a legitimate concern, I think. It would be like worrying that a vulnerability in OpenBSD affected NetBSD, too, especially if it was found relatively close to when OpenBSD forked.

Johnny_Brahms 11y ago

I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code. The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how anyone in their right mind writes C. If that is what is required to write safe C then I'm all for using another language. Edit: I do like how Zed Shaw writes C, but I have no idea if the software he wrote is safe...

smt88 11y ago
I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. I still think that will happen.
- masklinn 11y ago
  > I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. Yes and no. No in that LibreSSL aims to be mostly drop-in compatible with OpenSSL (modulo deprecations/removals) and OpenSSL has a very complex API exposing lots of internal gunk to the user, so moving to a non-C implementation may not be possible at all. Yes because there's a related `libtls`[0] project which aims to define more abstracted API (with the reference implementation being done on top of libressl). As POC, tedu has/had an implementation of the API using golang's TLS stack[1], and noted that you could build the same on e.g. the OCaml/Mirage TLS stack[2]. If `libtls` fulfils its promises, it would become much easier to swap TLS stack and indeed move to non-C implementations. [0] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/tls_accept_fds.3?query=tls%5finit&sec=3 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/... HN discussion: https://news.ycombinator.com/item?id=8572029 https://news.ycombinator.com/item?id=8572029 (some comments may not apply anymore IIRC the discussion was the initial API which has been extended since) [1] http://www.tedunangst.com/flak/post/goreSSL http://www.tedunangst.com/flak/post/goreSSL [2] https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/introducing-ocaml-tls
0x01 11y ago
If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution? Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely. I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!

peterwwillis 11y ago

laughs maniacally