This basically means libressl can not be used by the US Govt or any contractor working with the US Govt, which is a HUGE number of companies. By proxy, it means that libressl will not make its way into Fedora or RHEL, which also limits the adoption of it a fair bit.
Perhaps the solution is to fix FIPS instead of berating the people forced to use it.
I don't think lobbying the US Federal government is in OpenBSD developers' wheelhouse. Contractors working with the US government on the other hand have a long, distinguished history of successfully doing just that. In fact, that's largely the entire business model.
So it makes a lot of sense for each party to do what they are good at: OpenBSD developers write a clean, secure library, and contractors lobby to be allowed to use it.
I think OpenBSD has actually done contracted work for various U.S. government agencies. But on the other hand, I'm pretty sure that's the reason they've already ripped FIPS out and washed their hands of it... working on government projects is not fun and it's exactly the kind of thing they should outsource if they can.
Not unless RedHat is willing to foot the bill for FIPS certification of a variant, or wait for someone else to do it. The LibreSSL folks have indicated that they won't stand in the way of anyone who wants to do that (in this very note!). It just won't be them.
BTW, even some core OpenSSL developers think that the FIPS validation process is worse than useless. Here's OpenSSL developer Steve Marquess arguing that a FIPS-validated version of something will generally be less secure than the non-validated version (citing, in particular, how delays and cost of recertification can prevent deployment of fixes for known bugs):
But OpenSSL, as an organization, has so far been willing to play along with the process anyway. The difference is that the LibreSSL folks have enough of the courage of their convictions that they are not playing along.
Redhat already foots the bill for certification of the OpenSSL library they ship. They also foot the bill to have the versions of OpenSSH, dm-crypt, the kernel crypto api and libgcrypt certified.
Sounds good because it suggests sec industry disengagement. Probably simpler to do that and maintain it as a set of minimal patches to LibreSSL, because not many people need it. Either way, it should be secure by default.
US Govt or contractors can apply for a waiver that you can perpetually renew that will allow you to use non FIPS-140 certified cryptography in a product...
What isn't simple about Red Hat paying a third-party to write some software and get it certified? Other companies are doing it for themselves, surely Red Hat can find someone qualified.
Just "write some software and get it certified"? Sounds so simple, why doesn't everyone do it?
Because it isn't just getting a body of code certified once.
Someone has to maintain that specific code and either upstream or backport important changes which require a re-certification, neither of which LibreSSL is interested in helping with.
Once LibreSSL has reached a point of minimal disruptive change, FIPS support could be re-implemented as a series of third-party patches, which could then be certified as needed.
For example, create a fipssl project which is patches to a specific version of LibreSSL; take the result (LibreSSL v1.x + fipssl v1.2 = libfipssl v1.2) and then get that certified. Companies/contractors which need FIPS certification then use libfipssl v1.2.
The fipssl maintainers then just have to track LibreSSL changes until their next release, which (for a series of small, maintainable patches) shouldn't be too difficult. The grsecurity project has been doing the same thing with the Linux kernel for years.
Well, need & money, both of which Red Hat has. I am unclear how a company that maintains an enterprise distribution and writes a lot of code cannot find the folks needed to do FIPS if it is that important for their government contracts.
Perhaps the solution is to fix FIPS instead of berating the people forced to use it.