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.
Conversation
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.
1
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
Now forget OpenSSL entirely. I am saying that there might be other worthy OSS projects that deserve support, and if there's no ready to roll alternative, fund them, even if they're written in C.
1
E.g. PostgreSQL (don't know their funding situation). It's written in an unsafe language, but it'd take years of effort to rewrite it in anything else.
1
Sure, but it could be gradually rewritten in Rust and a lot of the code doesn't even need to be written in a memory safe language. It has a ton of management code, etc. which could be written in a higher-level language.
I don't think they'd be willing to do it even with funding.
2
My experience is that these projects don't value security enough to start doing that, and therefore shouldn't receive this kind of infrastructure security funding. It should be contingent on being willing to start making painful changes rather than just applying bandaids to it.
2
Don't really see point of giving a project a bunch of funding to start using sanitizers, fuzzers, modern mitigations, etc. if they aren't going to be doing that alongside longer term approaches. It's just a dead end. Makes sense to care about near/mid-term but not exclusively.
Funding should be contingent on being willing to start on those longer term projects. The biggest difference Google can make is changing the attitude / focus of these projects and giving them a huge incentive to care more about correctness / robustness / security than they do.
1
2
So if they just give no strings attached funding or fund specific work without it changing the way the project does things, I don't think that's particularly valuable, and that's why was so skeptical about the funding. I doubt it'll be open ended funding though.
2