3 ms·
> 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 bundle
by 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 agoKind 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 agoThis 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 agoBoth 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 agoDefining 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.