As also noted, pretty solid arguments can be made that the OpenBSD approach is the better approach. My point was that they're not mutually exclusive, and this is definitely a win-win scenario, as we have the potential to get 1. A rock-solid open source SSL library 2. Less surprises in the future.

> pretty solid arguments can be made that the OpenBSD approach is the better approach

Not really. OpenBSD is making a OpenSSL replacement for OpenBSD. They might make a portable version, but they might not. They have made it clear they are not putting the FIPS compliance stuff back in and there's a good chance a lot of those sponsors are interested in that.

Secondly, you don't get to choose where donations go in OpenBSD. You donate to OpenBSD and they distribute wherever. You don't get to say 'I need this money to go to improving the SSL library.' That can be kind of an issue for things like this.

FIPS is actively harmful to security by virtue of being an empty and ill-conceived certification. Removing FIPS from an otherwise best available option is to the benefit of the industry at large.

By comparison, glossy marketing of a security effort offers no security benefits, and plenty of room within which to hide bad ideas such as FIPS.

As others have said, the technical arguments against FIPS don't mean anything when a huge potential customer requires it.

And huge potential customers don't mean anything to a non-profit open source ecosystem that actually care about security.

When did Red Hat and Google become non-profits? Did I miss something?

RedHat and Google can afford to add FIPS to their own Libre SSL if they want to stop using OpenSSL.

Come on. We have every reason to believe that an OpenBSD library will be easily portable. That's their way. And FIPS was evil and had to go.

You think they can be made, but can you make them?

Money on its own can't code though. Money or no money, you need people who can and will start fixing shit.