3 ms·

It's fun to try to keep track of the SSL implementations distributions use/allow over time. Void, for example, started on OpenSSL, moved to LibreSSL, and then

It's fun to try to keep track of the SSL implementations distributions use/allow over time. Void, for example, started on OpenSSL, moved to LibreSSL, and then moved back [1]. Gentoo has always been OpenSSL by default, had serious motion towards enabling LibreSSL as a first class citizen, and then backed out of that effort [2]. And now Alpine is looking at their second switch from OpenSSL to LibreSSL. I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium; this back and forth stuff is going to get hard to keep track of (for application developers, at least). [1] https://voidlinux.org/news/2021/02/OpenSSL.html https://voidlinux.org/news/2021/02/OpenSSL.html [2] https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.gentoo.org/support/news-items/2021-01-05-libress...

arghwhat 5y ago
That Alpine is trying again suggests that even multiple attempts at migrating away is ultimately less stressful than remaining on OpenSSL...
- R0b0t1 5y ago
  There's people still trying on Gentoo, it's just not as easy as it immediately looks.
orra 5y ago
> I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium Distros seem to have shifted towards using bundled libraries for browsers. In this case, Chromium uses BoringSSL. It's too much effort to diverge from the upstream browsers. Besides, security teams for browsers tend to be better staffed than for distros.
- XorNot 5y ago
  Kind of wish we'd move TLS into the kernel at this point. Centralize the developer attention on it, and acknowledge that if the kernel is going to provide TCP sockets, it should provide all the tooling needed to secure those sockets as well. It's not a perfectly logical argument, but kernels get patched and upgraded more often then almost any other software.
  - klardotsh 5y ago
    This would probably work fairly well for desktop/server stuff, but I can only imagine the blast radius of this decision in Android devices with often limited at best OEM update support...
  - wahern 5y ago
    Both FreeBSD (https://www.freebsd.org/cgi/man.cgi?query=ktls&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=ktls&sektion=4) and Linux (https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html) support kernel TLS. Though only for the bulk encryption. Stream initiation and certificate verification is too complex, with more regularly changing requirements and features. So most developers would still end up using an SSL library like OpenSSL to avoid having to directly use the more complex kernel interfaces and data processing dance on connection.
    - XorNot 5y ago
      Defining a common syscall interface for stream initiation and cert verification, and then implementing the logic as a Linux kernel module would be a decent compromise I think.
lonjil 5y ago
It seems like Alpine's attempt at upgrading to OpenSSL 3.0 caused them a fair bit of stress, only a bit of which was caused by applications still using ancient deprecated APIs.

arghwhat 5y ago

That Alpine is trying again suggests that even multiple attempts at migrating away is ultimately less stressful than remaining on OpenSSL...

R0b0t1 5y ago
There's people still trying on Gentoo, it's just not as easy as it immediately looks.

orra 5y ago

> I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium Distros seem to have shifted towards using bundled libraries for browsers. In this case, Chromium uses BoringSSL. It's too much effort to diverge from the upstream browsers. Besides, security teams for browsers tend to be better staffed than for distros.

XorNot 5y ago
Kind of wish we'd move TLS into the kernel at this point. Centralize the developer attention on it, and acknowledge that if the kernel is going to provide TCP sockets, it should provide all the tooling needed to secure those sockets as well. It's not a perfectly logical argument, but kernels get patched and upgraded more often then almost any other software.
- klardotsh 5y ago
  This would probably work fairly well for desktop/server stuff, but I can only imagine the blast radius of this decision in Android devices with often limited at best OEM update support...
- wahern 5y ago
  Both FreeBSD (https://www.freebsd.org/cgi/man.cgi?query=ktls&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=ktls&sektion=4) and Linux (https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html) support kernel TLS. Though only for the bulk encryption. Stream initiation and certificate verification is too complex, with more regularly changing requirements and features. So most developers would still end up using an SSL library like OpenSSL to avoid having to directly use the more complex kernel interfaces and data processing dance on connection.
  - XorNot 5y ago
    Defining a common syscall interface for stream initiation and cert verification, and then implementing the logic as a Linux kernel module would be a decent compromise I think.

lonjil 5y ago

It seems like Alpine's attempt at upgrading to OpenSSL 3.0 caused them a fair bit of stress, only a bit of which was caused by applications still using ancient deprecated APIs.