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.
Conversation
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.
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.
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.
1
1
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
Show replies
I like with the contingency idea. I guess funding them to do useful security work was something I should have explicitly stated ;) they shouldn't be given the money for a nicer website :P
1
I think it should be required that they're at least willing to start doing the longer term things rather than say, spending all the money on fuzzing, fixing bugs and catching up to 2021 level memory corruption mitigations like deploying Clang CFI. It's just not compelling enough.
1
2
Show replies