* Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote:
> > * Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote:
> > > GnuTLS doesn't qualify.
> >
> > That should be "doesn't currently"..
> >
>
> Doesn't currently? Does that mean you know of a project to get FIPS certification for it? I don't.
"doesn't qualify" would imply that it's incapable of attaining FIPS
certification. I didn't make that claim, you did. Is there some reason
that GnuTLS is incapable of attaining FIPS certification that you know
of? Also, this is a very Debian-specific thread and quite a few other
Debian packages use GnuTLS instead of OpenSSL. I do not expect
PostgreSQL to drop support for OpenSSL, ever.
> The current OpenSSL has a version that is (the only source-code-level FIPS-140 certification ever).
Yes, I'm aware, I didn't dispute that.
> And yes, it is API compatible with the non-FIPS one. It just doesn't support some of the algorithms that the other
does.
When I looked into addressing this for our C&A'd systems it wasn't at
all clear that it was trivial to move from non-FIPS OpenSSL to
FIPS-compliant OpenSSL. Perhaps that's changed but, sadly, there's a
heck of a lot more encryption out there than just what OpenSSL will give
you (the Linux kernel being a primary example, but also the MIT Kerberos
libraries). Yes, it means you have to address that FISMA control, but
that's not an insurmountable problem and is, really, a reality for
anyone running a serious Linux-based environment, in my experience.
What I don't think people appreciate or realize is that there's a lot of
other encryption happening in their systems beyond what OpenSSL does.
> The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL.
> Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this).
This doesn't deserve a response.
Thanks,
Stephen