Android is a Linux distribution, and ChromeOS is one too. They could port it to replace the Bluetooth stack on ChromeOS and then other distributions could decide if they want to use it. I don't really think it makes sense for them to make something that won't really be used.
Conversation
Traditional Linux distributions have moved heavily towards more pervasive use of C rather than away from it via systemd. A lot of them are pretty unhappy with projects adopting Rust since it doesn't have support for all their architectures and is harder for them to handle.
1
1
I really don't think most traditional distributions are going to have much interest in most of the services and libraries being replaced with new implementations in Rust. Fedora would probably be fine with it. I can't see it being received well in Debian. It's a waste of effort.
1
I think we're diverging a little bit from my original point, so let me go back to it: I really hope they do fund stuff like Rustls for the widest possible adoption. But I still see a need to fix things being used *now* on live production systems.
1
My ultimate fear for their use of the money would be to throw it at stuff that only works with their specific systems and use cases and give up once these are sorted.
Strongly hoping that doesn't happen.
1
A lot of this work can't be done as part of existing projects and requires migrating to new software. For example, nginx has to keep up with the BoringSSL API changes. Their development focus is really BoringSSL rather than OpenSSL because OpenSSL can't do HTTP/3, etc.
1
A lot of what makes BoringSSL better than OpenSSL is that they dropped a bunch of platforms, replaced the APIs with better designed ones and overhauled all the code after dropping tons of configuration, portability, etc. It can't be so much better and also a drop-in replacement.
1
They also don't want to get stuck supporting stable APIs rather than being able to improve them over time, so there isn't a commitment to backwards compatibility for the APIs or legacy ciphers. The fact that it suits Google's needs means it suits any other reasonable uses though.
1
If you need more backwards compatibility from your TLS library than Google, something is seriously wrong. They have one of the most used websites in the world and have little tolerance for breaking it for even a tiny subset of users on broken legacy software.
1
And they have a lot of codebases to support with BoringSSL. It's really not hard to use it and to keep up with the changes. Of course, most open source projects using OpenSSL probably can't/won't keep up anyway. It doesn't benefit them because they don't bother supporting it.
Also worth noting that each major version of AOSP receives at least 3 years of support. Every major AOSP release is an LTS release. If you ported the code from Android 12, you'd be porting something with at least 3 years of security updates before mandatory upgrade to new branch.
1
Alright last messages then I'm done. I should stress that OpenSSL was just an example here, and I used it because it had high profile bugs, was relied upon by the world at large and received next to no funding. At the time, there was no Rust or BoringSSL alternative.
2
Show replies