None; it's an optional package you use when your users require FIPS 140.

It means companies with US government contracts writing Go code can use the standard library crypto package in native Go instead if having to enable CGO and using a crypto library written in C. CGO is kind of a pain in the ass to develop with compared to fully native Go code, especially when cross-compiling (and cross compilation is very common now that ARM is common on both laptops and servers).

This also now makes Go a very convenient language to write US Gov software in.

If you have never heard of FIPS before ignore this entirely and continue to live in happiness.

Would you say there’s a brown M&M’s aspect (intentional or otherwise) to FIPS-140, or is it all just bowing to the sovereign for his indulgences?

> Applications that have no need for FIPS 140-3 compliance can safely ignore [this page], and should not enable FIPS 140-3 mode.

https://go.dev/doc/security/fips140

Yup.

> Having said all this: nobody should be using crypto/fips140 unless they know specifically why they're doing that. Even in its 140-3 incarnation, FIPS 140 is mostly a genuflection to FedGov idiosyncrasies.

What should folks use then?

Does that mean it might be easier, regardless of language, to shell out to your cryptographic Go binary rather than deal with OpenSSL? I dislike a lot of Go, but they have been pretty good about backwards compatibility.

No, the Go 1.24 native module effort that they talk about in https://devblogs.microsoft.com/go/go-1-24-fips-update/ is this effort, which Microsoft was not involved in. We simply decided to delay the official announcement until the module reached the In Process list.

The system libraries approach used by Microsoft Go is cgo based IIUC, and I think derived from Go+BoringCrypto. I understand they are working on migrating their bindings to fit better downstream of the new native mode.

Companies don't need any additional reasons to skimp out on security.

The money could probably be more wisely spent if not following FIPS but without FIPS the average company wouldn't direct that money towards security at all.

[ Big I am a cryptographer, not your cryptographer disclaimer ]

It depends, but if you are targeting Security Level 1 (which is what most folks think about when they think about FIPS 140) you generally don't need your entire application to be validated, only the cryptographic module.

So (again, depending on your requirements and on the Operating Environment you deploy to and on what algorithms you use and how) setting GOFIPS140 might actually be all you need to do.

This is at est!