Quantcast

Debian readline/libedit breakage

classic Classic list List threaded Threaded
137 messages Options
12345 ... 7
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Joshua D. Drake
On Fri, 2011-02-11 at 14:59 -0500, [hidden email] wrote:
> If psql uses libreadline and libgnutls, does that mean psql will be distributed under the GPL in the future?  Or Dual-licensed?

libgnutls is libgpl, not GPL, so this is not a problem.

JD


--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Stephen Frost
In reply to this post by Greg Smith-21
Greg,

* Greg Smith ([hidden email]) wrote:
> Note that the past discussion was on the difficulty of matching the
> existing OpenSSL API using GnuTLS, which is apparently difficult to
> do.  

Oh, yes, that's more a reflection on the crappy API that OpenSSL has
than on anything else, in my view...

> I wasn't trying to suggest there were issues specificially with
> GnuTLS's code quality.  

Ah, I'm glad to hear that.

> You'd think there'd be a simple "OpenSSL-like" interface available
> for GnuTLS by now or something.

There is, but it was written by Steve Langasek (as I recall...) for when
this was done for OpenLDAP and was licensed under the GPL (and, yes, I
did bitch at him about this...  Didn't help. :/).

I'm not sure if that compatability layer would work (in terms of being
acceptable by core) for PG in any case tho.

        Thanks,

                Stephen

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Tom Lane-2
In reply to this post by Alvaro Herrera-7
Alvaro Herrera <[hidden email]> writes:
> Why do we have to involve the whole of PostgreSQL?  Since the only piece
> that links to libreadline is psql, perhaps we could fix this by having
> only psql optionally use GnuTLS.

We have code that exists in both psql and the backend (cf src/port/)
so I'm not sure this really will satisfy the more rabid GPL partisans.
And this whole discussion is about satisfying the most rabid of them,
remember.  I don't really think that anything other than "relicense all
of Postgres as GPL" will make them happy.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Robert Haas
On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <[hidden email]> wrote:

> Alvaro Herrera <[hidden email]> writes:
>> Why do we have to involve the whole of PostgreSQL?  Since the only piece
>> that links to libreadline is psql, perhaps we could fix this by having
>> only psql optionally use GnuTLS.
>
> We have code that exists in both psql and the backend (cf src/port/)
> so I'm not sure this really will satisfy the more rabid GPL partisans.
> And this whole discussion is about satisfying the most rabid of them,
> remember.  I don't really think that anything other than "relicense all
> of Postgres as GPL" will make them happy.

Which, by the way, *no one* has the authority to do.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Stephen Frost
In reply to this post by Charles.McDevitt
* [hidden email] ([hidden email]) wrote:
> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 compliance is essential to many Federal users.

Essential?  That's a bit much.  Yes, it shows up on a FISMA review as an
open action item, but it's a risk that can both be accepted and
mitigated.  I also thought FIPS-140 version required API changes..

> GnuTLS doesn't qualify.

That should be "doesn't currently"..

        Thanks,

                Stephen

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Tom Lane-2
In reply to this post by Robert Haas
Robert Haas <[hidden email]> writes:
> On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <[hidden email]> wrote:
>> We have code that exists in both psql and the backend (cf src/port/)
>> so I'm not sure this really will satisfy the more rabid GPL partisans.
>> And this whole discussion is about satisfying the most rabid of them,
>> remember.  I don't really think that anything other than "relicense all
>> of Postgres as GPL" will make them happy.

> Which, by the way, *no one* has the authority to do.

Right.  So the long term solution in my mind is to migrate away from
readline and towards libedit.  I'm just not sufficiently worried about
this to put any of my own cycles into making libedit good enough.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Stephen Frost
In reply to this post by Tom Lane-2
Tom,

* Tom Lane ([hidden email]) wrote:
> We have code that exists in both psql and the backend (cf src/port/)
> so I'm not sure this really will satisfy the more rabid GPL partisans.

We're talking Debian, who, yes, are a bit pickier when it comes to
trying to actually follow the licneses they release, but they're also
technically competent.  I expect the answer would depend on if the
backend process links against both readline and openssl or not.

> And this whole discussion is about satisfying the most rabid of them,
> remember.  I don't really think that anything other than "relicense all
> of Postgres as GPL" will make them happy.

Of course, relicensing it under the GPL wouldn't actually help this
situation, at all, nor has anyone brought it up that I'm aware of..

        Thanks,

                Stephen

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Daniel Farina-4
In reply to this post by Stephen Frost
On Fri, Feb 11, 2011 at 12:25 PM, Stephen Frost <[hidden email]> wrote:

> * [hidden email] ([hidden email]) wrote:
>> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 compliance is essential to many Federal users.
>
> Essential?  That's a bit much.  Yes, it shows up on a FISMA review as an
> open action item, but it's a risk that can both be accepted and
> mitigated.  I also thought FIPS-140 version required API changes..
>
>> GnuTLS doesn't qualify.
>
> That should be "doesn't currently"..

Not being a SSL aficionado by any means, but what about NSS? That's
pretty mature, and could be another viable option.

--
fdr

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Martijn van Oosterhout
In reply to this post by Greg Smith-21
On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote:
> Note that the past discussion was on the difficulty of matching the  
> existing OpenSSL API using GnuTLS, which is apparently difficult to do.  
> I wasn't trying to suggest there were issues specificially with GnuTLS's  
> code quality.  It's more that the APIs are just different enough that  
> it's not trivial to do a swap--which is surprising given how many people  
> have seemingly needed to do exactly this conversion.  You'd think  
> there'd be a simple "OpenSSL-like" interface available for GnuTLS by now  
> or something.

I spent some time a while back making PostgreSQL work with GnuTLS. The
actual SSL bit is trivial. The GnuTLS interface actually made sense
whereas the OpenSSL one is opaque (at least, I've never seen any
structure in it). The GnuTLS interface was designed in the modern era
and it shows.

The problems are primarily that psql exposes in various ways that it
uses OpenSSL and does it in ways that are hard to support backward
compatably. So for GnuTLS support you need to handle all those bits
too.

For example, the patch as presented introduced a passthrough mode that
allowed applications to read/write over the SSL connection without
actually knowing the underlying library. It had to fix psql to use this
info. It had to provide ways for applications to determine the info
they needed about the SSL, since it wouldn't beable to just grab the
OpenSSL handle.

All this made the patch large, which caused it to be rejected. I found
that odd since the bulk of the patch was the renaming of two files,
which makes for huge diffs while the changes where minimal. I beleive
git is smarter about renames which means the diff may magically become
much smaller just by using git, yay!

Supporting GnuTLS for that backend was just icing, but trivial once the
frontend was done. It can be left out.

Have a nice day,
--
Martijn van Oosterhout   <[hidden email]>   http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
>                                       - Charles de Gaulle

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Robert Haas
On Fri, Feb 11, 2011 at 5:22 PM, Martijn van Oosterhout
<[hidden email]> wrote:

> On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote:
>> Note that the past discussion was on the difficulty of matching the
>> existing OpenSSL API using GnuTLS, which is apparently difficult to do.
>> I wasn't trying to suggest there were issues specificially with GnuTLS's
>> code quality.  It's more that the APIs are just different enough that
>> it's not trivial to do a swap--which is surprising given how many people
>> have seemingly needed to do exactly this conversion.  You'd think
>> there'd be a simple "OpenSSL-like" interface available for GnuTLS by now
>> or something.
>
> I spent some time a while back making PostgreSQL work with GnuTLS. The
> actual SSL bit is trivial. The GnuTLS interface actually made sense
> whereas the OpenSSL one is opaque (at least, I've never seen any
> structure in it). The GnuTLS interface was designed in the modern era
> and it shows.
>
> The problems are primarily that psql exposes in various ways that it
> uses OpenSSL and does it in ways that are hard to support backward
> compatably. So for GnuTLS support you need to handle all those bits
> too.
>
> For example, the patch as presented introduced a passthrough mode that
> allowed applications to read/write over the SSL connection without
> actually knowing the underlying library. It had to fix psql to use this
> info. It had to provide ways for applications to determine the info
> they needed about the SSL, since it wouldn't beable to just grab the
> OpenSSL handle.
>
> All this made the patch large, which caused it to be rejected. I found
> that odd since the bulk of the patch was the renaming of two files,
> which makes for huge diffs while the changes where minimal. I beleive
> git is smarter about renames which means the diff may magically become
> much smaller just by using git, yay!
>
> Supporting GnuTLS for that backend was just icing, but trivial once the
> frontend was done. It can be left out.

We should probably revisit this for 9.2.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Charles.McDevitt
In reply to this post by Stephen Frost
> * [hidden email] ([hidden email]) wrote:
> > Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140
> compliance is essential to many Federal users.
>
> Essential?  That's a bit much.  Yes, it shows up on a FISMA review as an
> open action item, but it's a risk that can both be accepted and
> mitigated.  I also thought FIPS-140 version required API changes..
>
> > 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.

The current OpenSSL has a version that is (the only source-code-level FIPS-140 certification ever).
And yes, it is API compatible with the non-FIPS one.  It just doesn't support some of the algorithms that the other 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).

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Greg Stark-3
On Fri, Feb 11, 2011 at 11:06 PM,  <[hidden email]> wrote:
> 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 is just libelous FUD. There's absolutely no reason postgres would
have to be GPL'd to satisfy any library license. In fact doing so
would make the problem worse, not better since then the license on
Postgres itself would (allegedly) conflict with the OpenSSL license.

There's no question that the resulting binary when linked with
readline is covered by the GPL including shipping source code etc.
This is non-controversial and the
original intent of licensing readline under the GPL. This isn't the
same question as GIMP plugins or code using GMP which are themselves
functionally dependent on the GPL'd code and some claim are therefore
derivative works. I don't think anyone would
claim that Postges is a derivative work of readline.

The only question here is whether the OpenSSL license imposes
requirements which cannot be met at the same time as the GPL
requirements. The rest of Postgres itself doesn't conflict but if
you're distributing a binary then you're covered by all the licenses
of the code you include and depend on (the last part is somewhat
controversial but irrelevant to this topic since OpenSSL headers are
already included). So if the OpenSSL license imposes restrictions that
the GPL bars then the resulting binary is not distributable.

I suspect RedHat may have determined that the OpenSSL license
requirements are not in fact mutually exclusive with the GPL either
because they're not enforceable at all in the US anyways or because
the way they read them they can be satisfied without violating the
GPL. It's also possible they just decided it's unlikely the OpenSSL
people would ever sue or the damages would be negligable. Of course
this is all speculation.

--
greg

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Charles.McDevitt
 -----Original Message-----

> From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Stark
> Sent: Friday, February 11, 2011 4:03 PM
> On Fri, Feb 11, 2011 at 11:06 PM,  <[hidden email]> wrote:
> > 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 is just libelous FUD. There's absolutely no reason postgres would
> have to be GPL'd to satisfy any library license.

Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional requirements.

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Greg Stark-3
On Sat, Feb 12, 2011 at 12:07 AM,  <[hidden email]> wrote:
>> This is just libelous FUD. There's absolutely no reason postgres would
>> have to be GPL'd to satisfy any library license.
>
> Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional requirements.

No

--
greg

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Charles.McDevitt
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Stark
> Sent: Friday, February 11, 2011 4:14 PM
> To: McDevitt, Charles
> Cc: [hidden email]; [hidden email];
> [hidden email]; [hidden email]; [hidden email];
> [hidden email]; [hidden email]; pgsql-
> [hidden email]
> Subject: Re: Debian readline/libedit breakage
>
> On Sat, Feb 12, 2011 at 12:07 AM,  <[hidden email]> wrote:
> >> This is just libelous FUD. There's absolutely no reason postgres would
> >> have to be GPL'd to satisfy any library license.
> >
> > Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional
> requirements.
>
> No

What?  From the GNU Readline home page:  "Readline is free software, distributed under the terms of the GNU General Public License, version 3."

I know it used to be GPLv2, but that isn't true these days.

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Stephen Frost
In reply to this post by Charles.McDevitt
* [hidden email] ([hidden email]) wrote:
> > * [hidden email] ([hidden email]) 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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Greg Stark-3
In reply to this post by Charles.McDevitt
On Sat, Feb 12, 2011 at 12:15 AM,  <[hidden email]> wrote:
>> > Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional
>> requirements.
>>
>> No
>
> What?  From the GNU Readline home page:  "Readline is free software, distributed under the terms of the GNU General Public License, version 3."
>
> I know it used to be GPLv2, but that isn't true these days.

There's nothing in the GPLv3 which changes things in this case.



--
greg

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Greg Smith-21
In reply to this post by Charles.McDevitt
[hidden email] wrote:
> 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).
>  

The "GNU people" are perfectly content with the license of PostgreSQL.  
They are unhappy with the license terms of OpenSSL, which is fair
because they are ridiculous.  Eric Young and the rest of the
contributors produced a useful piece of software, and made it considerly
less valuable to the world due to the ego trip terms:  
http://www.openssl.org/source/license.html -- the worst specific problem
is the requirement to acknowledge OpenSSL use in advertising of projects
that use it.

The PostgreSQL community has had similar issues with popular software
commonly used on top of PostgreSQL, that happened to use a non-standard
license with unique terms.  It would be both hypocritical and incorrect
to now blame the GNU projects for taking a similar stand on this one.

--
Greg Smith   2ndQuadrant US    [hidden email]   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Dimitri Fontaine-7
In reply to this post by Tom Lane-2
Tom Lane <[hidden email]> writes:
> Less narrow-minded interpretation of GPL requirements, perhaps.
> (And yes, we have real lawyers on staff considering these issues.)

If we really believe that the debian interpretation of the licence issue
here is moot, surely the easiest action is to offer a debian package
repository hosted in the postgresql.org infrastructure.

That would also allow us to maintain all our currently supported
versions and choose to consider reaching EOL of one of them where it's
still included in a stable debian releases.  Debian folks can't do that
and as a result they will only ship one major version at a time, which
certainly is a shame.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debian readline/libedit breakage

Magnus Hagander-2
On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine <[hidden email]> wrote:

> Tom Lane <[hidden email]> writes:
>> Less narrow-minded interpretation of GPL requirements, perhaps.
>> (And yes, we have real lawyers on staff considering these issues.)
>
> If we really believe that the debian interpretation of the licence issue
> here is moot, surely the easiest action is to offer a debian package
> repository hosted in the postgresql.org infrastructure.
>
> That would also allow us to maintain all our currently supported
> versions and choose to consider reaching EOL of one of them where it's
> still included in a stable debian releases.  Debian folks can't do that
> and as a result they will only ship one major version at a time, which
> certainly is a shame.

Yeah, I've been thinking about that before, for other reasons. It's
fallen down so far on the fact that our current packager (Martin)
isn't too interested in doing it, and he's been the one with the
cycles and experience...

Are you volunteering? ;)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
12345 ... 7
Loading...