Everything looked correct. OpenSSL 3 with the FIPS provider enabled. Ruby built against it. A simple pg connection worked.
The app failed once ActiveRecord was involved. The error came from libpq. It turned out the pg gem had pulled in a prebuilt native dependency that was linked against different crypto. That path was always there. It just was not exercised until ActiveRecord hit it.
Forcing a source build fixed the issue because the extension then linked against the OpenSSL in the image.
The takeaway is that a FIPS base image does not mean your dependency graph respects the same boundary once native code is involved.
Curious how others have seen this play out in Ruby, Python wheels, Go with CGO, or Node native addons.
JasonADrury•2w ago
Yes, gotta implement that Dual_EC_DRBG compatibility.
FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent. It's also significantly worse advice than simple "implement decent modern crypto", you can do all kinds of really bizarre stuff and still be FIPS compliant.
pixl97•2w ago
I counter about the benefits of FIPS. If you don't do it, you don't get paid by the government for whatever contract you have. Many people find getting paid to be beneficial.
Now, it's not the vast majority of applications, but I'm sure there are a significant number of developers on HN that are working on applications that need to meet FedRamp requirements and posts like this point out potential pitfalls on what needs enabled.
Not much different when dealing with stuff like STIGs. A large number of them are highly questionable and may only apply to very specific applications, yet you see barely trained button pushers saying you need to follow them. If you're aware of them when writing your application it will save a bunch of implementation headaches when it ends up in the field.
firesteelrain•2w ago
Not the entire RHEL STIG mind you but parts of it
pixl97•2w ago
JasonADrury•2w ago
I absolutely agree, but the OP does speak about making "the entire software supply chain safer" which is far from true.
tptacek•2w ago
JasonADrury•2w ago
I think the problem with FIPS can be summed up very well as "it doesn't require you to implement good crypto", which makes it pointless and almost certainly harmful.
firesteelrain•2w ago
JasonADrury•2w ago
FIPS would be great if it actually explicitly required you to do things correctly, it does not.
firesteelrain•2w ago
akerl_•2w ago
dragonwriter•2w ago
Alternatively, do you deal with HIPAA PHI (FIPS is—unless an update since the last time I checked has changed this—part of the HITECH Act guidance specification of whether PHI is secured or unsecured, and so is a factor in whether, legally, a breach has occurred.)
akerl_•2w ago
dragonwriter•2w ago
akerl_•2w ago
Choosing to use FIPS is basically choosing to tether yourself to the finest decision-making that government agencies could muster based on the technology that existed decades ago.
You’re choosing to ride a horse to work because somebody whacked an “approved” brand on it. I’m sure it’s a very reliable horse, but unless somebody is paying me a lot of money to hold the reins, I’m going to opt to use the advances we’ve made as an industry since then
dragonwriter•2w ago
I haven't said anything about the quality of the assessment done as part of FIPS approval. I think you are straining for things to disagree with.
> Choosing to use FIPS is basically choosing to tether yourself to the finest decision-making that government agencies could muster based on the technology that existed decades ago.
The current FIPS encryption standards and criteria were not decided decades ago, or based on technology adopted decades ago (FIPS 140-3 is 2019, SP 800-40 is 2023, etc.)
Beyond the basic idea of “Let’s have NIST establish standards in this area”, almost nothing is from “decades ago”.
tptacek•2w ago