[AaronFriel]

The comment is accurate that if you don't need this, you can ignore it. It's likely not an avenue for backdoors. I wouldn't say it's security theater but it just isn't meaningful to most.

As for why not a library? Go has a pretty big "batteries included" implementation for networking. For customers demanding FIPS compliance it isn't enough to say, write all of your own application code to use a package that does FIPS-compliant TLS, but you have to make sure all of your libraries also use those algorithms. No rational person is going to vendor their entire dependency tree and maintain forks of the entire universe to swap `crypto/tls` and `net/http`. Well, some of these contracts are big enough to justify it, but whew, what a waste.

The FIPS compliant Go builds from Microsoft and now Go 1.24 make it a lot easier to check that box and unless a package implemented their own TLS stack it's easy to attest that the software uses FIPS validated crypto modules. Without that, good luck trying to sell to gov and highly regulated institutions in financial and health.

[dagss]

Wouldn't declaring the "replace" directive in go.mod once take effect for all the dependencies?

[AaronFriel]

Oh that's an interesting question, I've never tried to build a binary with "replace"-ing one of the builtin packages.

Maybe that works? But many of the standard library packages use linker shenanigans, if I recall, like //go:linkname pragmas. Maybe that's an issue, maybe not?

It would be interesting if the fork was unnecessary and it was possible to implement FIPS via package replacements! That would be a lot simpler.

[adonovan]

"replace" is an operation on modules. Networking is part of the standard library, which is a single (very special) module. Even if you could "replace" std, it would not really be less than creating a fork.