Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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...



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.


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.


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.


I read that will be sorted in go 1.25

https://devblogs.microsoft.com/go/go-1-24-fips-update/


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/

[2] https://news.ycombinator.com/item?id=40178652




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: