Re: Debian readline/libedit breakage

* Charles(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)com) wrote:
> > * Charles(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)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