4 ms·

> When GODEBUG=fips140=only is used, in addition to the above, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Not su

> When GODEBUG=fips140=only is used, in addition to the above, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Not sure I love the idea of stdlib panicking on purpose here. I haven't looked at the code, but I wonder if it's just in functions that don't currently return an error for backwards compat...

sundbry 2y ago
Then don't set the flag... This kind of behavior is useful when things are only detectable at runtime. Rudimentary test coverage would uproot it.
studmuffin650 2y ago
This is a feature that’s required in Government environments. You need a check at runtime to ensure that FIPS is set or you run the risk of breaking compliance. Which leads to inevitable audits and endless meetings. I would much prefer a panic causing an issue for 30 minutes vs. endless days of meetings to set up new controls and validations that will make your life more miserable.
p_l 2y ago
As sibling comments mentioned, someone's you want to enforce things. Also consider it a way to avoid hidden bugs, similar to "The server chose violence" [1] [2] as well as how much Postel's law held back interoperability (which is forgotten by many aspect of FIPS certifications) [1] https://cliffle.com/blog/hubris-reply-fault/ https://cliffle.com/blog/hubris-reply-fault/ [2] https://news.ycombinator.com/item?id=40178652 https://news.ycombinator.com/item?id=40178652
gedw99 2y ago
I read that will be sorted in go 1.25 https://devblogs.microsoft.com/go/go-1-24-fips-update/ https://devblogs.microsoft.com/go/go-1-24-fips-update/
Cthulhu_ 2y ago
The only real alternative is erroring, but those can be caught and ignored - is that something that is desireable when encryption is at stake? Warning log levels should be avoided; it's either important and actionable (error or fatal), or it isn't, in which case it's 'info' log level. I had a blog post about it (appeal to authority) but I can't find it at the moment.

sundbry 2y ago

Then don't set the flag... This kind of behavior is useful when things are only detectable at runtime. Rudimentary test coverage would uproot it.

studmuffin650 2y ago

This is a feature that’s required in Government environments. You need a check at runtime to ensure that FIPS is set or you run the risk of breaking compliance. Which leads to inevitable audits and endless meetings. I would much prefer a panic causing an issue for 30 minutes vs. endless days of meetings to set up new controls and validations that will make your life more miserable.

p_l 2y ago

As sibling comments mentioned, someone's you want to enforce things. Also consider it a way to avoid hidden bugs, similar to "The server chose violence" [1] [2] as well as how much Postel's law held back interoperability (which is forgotten by many aspect of FIPS certifications) [1] https://cliffle.com/blog/hubris-reply-fault/ https://cliffle.com/blog/hubris-reply-fault/ [2] https://news.ycombinator.com/item?id=40178652 https://news.ycombinator.com/item?id=40178652

gedw99 2y ago

I read that will be sorted in go 1.25 https://devblogs.microsoft.com/go/go-1-24-fips-update/ https://devblogs.microsoft.com/go/go-1-24-fips-update/

Cthulhu_ 2y ago

The only real alternative is erroring, but those can be caught and ignored - is that something that is desireable when encryption is at stake? Warning log levels should be avoided; it's either important and actionable (error or fatal), or it isn't, in which case it's 'info' log level. I had a blog post about it (appeal to authority) but I can't find it at the moment.