It's going pretty fast for AOSP. Everyone using supported Pixels will get an over-the-air update to Android 12 bringing the Rust Bluetooth stack. I expect they'll be introducing dramatically more of it for Android 13 as long as deploying it for Android 12 goes well.
Conversation
So the real question is can I separate out that Rust bluetooth stack and use it on a Linux distro? Will they contribute support to built it standalone so distros can benefit too?
Unfortunately there's more than just Android to improve.
2
Android has heavily used a memory safe language from the beginning: Java.
I don't think it's up to Google to convince traditional distributions their approach to security is terrible: ill-defined base system cobbled together from fragmented projects without overall security.
1
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.
1
1
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.
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
Show replies