Re: [HACKERS] GnuTLS support

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-29 16:34:13 -0500, Tom Lane wrote: > > Yeah, I was disappointed too. OpenSSL has had a squirrelly enough track > > record that it'd be nice not to be totally dependent on it. > > GnuTLS seems, if anything, worse though. There's

Re: [HACKERS] GnuTLS support

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut > > wrote: > >> I have decided that I don't want to pursue this patch anymore. It has > >> served its purpose having allowed us to refine the SSL library > >>

Re: [HACKERS] GnuTLS support

Hi, On 2018-11-29 16:34:13 -0500, Tom Lane wrote: > Yeah, I was disappointed too. OpenSSL has had a squirrelly enough track > record that it'd be nice not to be totally dependent on it. GnuTLS seems, if anything, worse though. There's obviously good reasons to add support for TLS libraries that

Re: [HACKERS] GnuTLS support

Robert Haas writes: > On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut > wrote: >> I have decided that I don't want to pursue this patch anymore. It has >> served its purpose having allowed us to refine the SSL library >> abstractions so that alternative implementations such as macOS Secure >>

Re: [HACKERS] GnuTLS support

On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut wrote: > On 29/11/2018 13:28, Dmitry Dolgov wrote: > > Unfortunately it needs to be rebased one more time, could you do this? Also > > I'm > > wondering about this: > > > >> I'm moving this patch forward to CF 2018-09, since it's not going to be >

Re: [HACKERS] GnuTLS support

On 29/11/2018 13:28, Dmitry Dolgov wrote: > Unfortunately it needs to be rebased one more time, could you do this? Also > I'm > wondering about this: > >> I'm moving this patch forward to CF 2018-09, since it's not going to be >> ready for -07, and we're still whacking around some channel

Re: [HACKERS] GnuTLS support

> On Fri, Aug 31, 2018 at 1:28 PM Peter Eisentraut > wrote: > > On 20/08/2018 05:13, Michael Paquier wrote: > > Patch v6 of this thread is failing to apply. Could you rebase? > > attached > > Changes in v7 since v6: > > - Added support for ssl_passphrase_command. > > - Test suite needed some

Re: [HACKERS] GnuTLS support

On 20/08/2018 05:13, Michael Paquier wrote: > Patch v6 of this thread is failing to apply. Could you rebase? attached Changes in v7 since v6: - Added support for ssl_passphrase_command. - Test suite needed some adjustment because GnuTLS doesn't appear to understand the previously used file

Re: [HACKERS] GnuTLS support

On Thu, Mar 08, 2018 at 02:13:51PM -0500, Peter Eisentraut wrote: > In the thread about Secure Transport we agreed to move the consideration > of new SSL libraries to PG12. > > Here is my current patch, after all the refactorings. > > The status is that it works fine and could be used. > >

Re: [HACKERS] GnuTLS support

On 05/06/18 00:44, Peter Eisentraut wrote: On 6/2/18 16:50, Heikki Linnakangas wrote: On 08/03/18 14:13, Peter Eisentraut wrote: There are two failures in the SSL tests that I cannot explain. The tests are for some rather obscure configurations, so the changed behaviors are not obviously

Re: [HACKERS] GnuTLS support

On 3/8/18 20:13, Peter Eisentraut wrote: > In the thread about Secure Transport we agreed to move the consideration > of new SSL libraries to PG12. > > Here is my current patch, after all the refactorings. > > The status is that it works fine and could be used. > > There are two failures in the

Re: [HACKERS] GnuTLS support

On 6/2/18 16:50, Heikki Linnakangas wrote: > On 08/03/18 14:13, Peter Eisentraut wrote: >> There are two failures in the SSL tests that I cannot explain. The >> tests are for some rather obscure configurations, so the changed >> behaviors are not obviously wrong, perhaps legitimate implementation

Re: [HACKERS] GnuTLS support

On 08/03/18 14:13, Peter Eisentraut wrote: There are two failures in the SSL tests that I cannot explain. The tests are for some rather obscure configurations, so the changed behaviors are not obviously wrong, perhaps legitimate implementation differences. But someone wrote those tests with a

Re: [HACKERS] GnuTLS support

In the thread about Secure Transport we agreed to move the consideration of new SSL libraries to PG12. Here is my current patch, after all the refactorings. The status is that it works fine and could be used. There are two failures in the SSL tests that I cannot explain. The tests are for some

Re: [HACKERS] GnuTLS support

On Thu, Feb 1, 2018 at 5:08 AM, Christoph Berg wrote: > Re: Peter Eisentraut 2018-01-03 > <99680dba-cf63-8151-1de2-46ca93897...@2ndquadrant.com> >> One scenario is that if GnuTLS goes in, it's quite plausible that the >> PG11 packages for Debian and Ubuntu will use it by

Re: [HACKERS] GnuTLS support

Re: Peter Eisentraut 2018-01-03 <99680dba-cf63-8151-1de2-46ca93897...@2ndquadrant.com> > One scenario is that if GnuTLS goes in, it's quite plausible that the > PG11 packages for Debian and Ubuntu will use it by default. But if it > doesn't support tls-server-endpoint, then a JDBC client

Re: [HACKERS] GnuTLS support

On 01/26/2018 03:54 AM, Peter Eisentraut wrote: On 1/25/18 20:10, Michael Paquier wrote: Peter, could you change ssl_version() and ssl_cipher() in sslinfo at the same time please? I think that those should use the generic backend-side APIs as well. sslinfo depends heavily on OpenSSL, OK, but if

Re: [HACKERS] GnuTLS support

On Mon, Jan 29, 2018 at 09:16:56PM -0500, Peter Eisentraut wrote: > On 1/28/18 23:43, Michael Paquier wrote: >> The comment at the top of PQinitSSL mentions OpenSSL, you may want to >> get rid of it as well. > > I think that whole business is actually obsolete as of OpenSSL 1.1.0 and > not

Re: [HACKERS] GnuTLS support

Hi, On 2018-01-29 22:41:53 -0500, Tom Lane wrote: > But I think a big part of the value here is to verify that we've > cleaned up our internal APIs to the point where a different SSL/TLS > implementation *could* be rolled underneath. Yea, I completely agree with that. > As part of that, we

Re: [HACKERS] GnuTLS support

Andres Freund writes: > FWIW, I'm -0.5 on adding gnutls support. I've not seen any non-vague > arguments for it, and having debugged gnutls using applications in the > past, I'm not convinced we're not primarily increasing our workload by > adding support. If gnutls would

Re: [HACKERS] GnuTLS support

On Mon, Jan 29, 2018 at 07:39:33PM -0500, Peter Eisentraut wrote: > I think most users actually still think about the whole topic as "SSL", > and the leading library is called "OpenSSL", so I think we're fine. Yes, that's my impression on the matter as well. While renaming the client-side

Re: [HACKERS] GnuTLS support

On Mon, Jan 29, 2018 at 06:24:18PM -0800, Andres Freund wrote: > FWIW, I'm -0.5 on adding gnutls support. I've not seen any non-vague > arguments for it, and having debugged gnutls using applications in the > past, I'm not convinced we're not primarily increasing our workload by > adding support.

Re: [HACKERS] GnuTLS support

On 2018-01-17 12:30:16 -0500, Peter Eisentraut wrote: > On 1/2/18 10:35, Peter Eisentraut wrote: > > On 11/26/17 20:05, Andreas Karlsson wrote: > >> I have now implemented this in the attached patch (plus added support > >> for channel binding and rebased it) but I ran into one issue which I >

Re: [HACKERS] GnuTLS support

On Sat, Jan 27, 2018 at 05:00:17PM -0500, Peter Eisentraut wrote: > On 1/25/18 09:07, Peter Eisentraut wrote: >> On 1/19/18 13:43, Peter Eisentraut wrote: >>> Comparing the existing {be,fe}-secure-openssl.c with the proposed >>> {be,fe}-secure-gnutls.c, and with half an eye on the previously

Re: [HACKERS] GnuTLS support

On Wed, Jan 17, 2018 at 10:02:35PM -0500, Tom Lane wrote: > That is a really good point. For precedent, note that darn near nobody > seems to know whether their psql contains readline or libedit. If we > force the issue by giving the settings different names, then they'll be > forced to figure

Re: [HACKERS] GnuTLS support

On 1/25/18 09:07, Peter Eisentraut wrote: > On 1/19/18 13:43, Peter Eisentraut wrote: >> Comparing the existing {be,fe}-secure-openssl.c with the proposed >> {be,fe}-secure-gnutls.c, and with half an eye on the previously proposed >> Apple Secure Transport implementation, I have identified a few

Re: [HACKERS] GnuTLS support

> On 26 Jan 2018, at 02:10, Michael Paquier wrote: > On Fri, Jan 26, 2018 at 12:27:16AM +0100, Daniel Gustafsson wrote: >> While only tangentially related to the issue this patch solves, converting >> be_tls_get_peerdn_name() to return const char * seems reasonable too

Re: [HACKERS] GnuTLS support

On 1/25/18 20:10, Michael Paquier wrote: > Peter, could you change ssl_version() and ssl_cipher() in sslinfo at the > same time please? I think that those should use the generic backend-side > APIs as well. sslinfo depends heavily on OpenSSL, OK, but if possible > getting this code more generic

Re: [HACKERS] GnuTLS support

On Fri, Jan 26, 2018 at 12:27:16AM +0100, Daniel Gustafsson wrote: >> On 25 Jan 2018, at 15:07, Peter Eisentraut >> wrote: >> >> On 1/19/18 13:43, Peter Eisentraut wrote: >>> Comparing the existing {be,fe}-secure-openssl.c with the proposed >>>

Re: [HACKERS] GnuTLS support

On Fri, Jan 19, 2018 at 01:55:30PM -0500, Robert Haas wrote: > On Wed, Jan 17, 2018 at 10:02 PM, Tom Lane wrote: >> Also, this isn't really a good argument against using uniform names >> for parameters that every implementation is certain to have, like >> ssl_key_file. > >

Re: [HACKERS] GnuTLS support

> On 25 Jan 2018, at 15:07, Peter Eisentraut > wrote: > > On 1/19/18 13:43, Peter Eisentraut wrote: >> Comparing the existing {be,fe}-secure-openssl.c with the proposed >> {be,fe}-secure-gnutls.c, and with half an eye on the previously proposed >> Apple Secure

Re: [HACKERS] GnuTLS support

Comparing the existing {be,fe}-secure-openssl.c with the proposed {be,fe}-secure-gnutls.c, and with half an eye on the previously proposed Apple Secure Transport implementation, I have identified a few more areas of refactoring that should be done in order to avoid excessive copy-and-pasting in

Re: [HACKERS] GnuTLS support

On Wed, Jan 17, 2018 at 6:48 PM, Tomas Vondra wrote: > What would be much worse is if a particular GUC did not have a matching > concept in the library. Say if an SSL library did not have a concept of > priority strings and instead used some other concept affecting

Re: [HACKERS] GnuTLS support

On 01/17/2018 11:14 PM, Peter Eisentraut wrote: > On 1/17/18 14:05, Tom Lane wrote: >> Although these corner cases are starting to make me feel like >> changing my original vote. Maybe we should forget the prefixes, in >> particular renaming gnutls_priorities to ssl_priorities, and just >>

Re: [HACKERS] GnuTLS support

On 1/17/18 14:05, Tom Lane wrote: > Although these corner cases are starting to make me feel like changing > my original vote. Maybe we should forget the prefixes, in particular > renaming gnutls_priorities to ssl_priorities, and just accept the need > to document some parameters as only relevant

Re: [HACKERS] GnuTLS support

On 1/17/18 13:18, Tom Lane wrote: >> The proposed GnuTLS patch does make use of ssl_dh_params_file. > > Right, but what happens if say macTLS doesn't? The previously proposed patch for that also makes use of ssl_dh_params_file. So while we can't guarantee that this will be the case for all TLS

Re: [HACKERS] GnuTLS support

Magnus Hagander writes: > On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote: >> What I don't want to end up with is an unholy mixture of both approaches. >> Therefore, if we are going to use method #2, we must be certain that >> the basic "ssl_" parameters

Re: [HACKERS] GnuTLS support

On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote: > Peter Eisentraut writes: > > On 1/17/18 12:39, Tom Lane wrote: > >> I don't know too much about the internals here, so looking at your > >> list, I wonder whether "ssl_dh_params_file" ought

Re: [HACKERS] GnuTLS support

On 1/17/18 12:39, Tom Lane wrote: > I don't know too much about the internals here, so looking at your > list, I wonder whether "ssl_dh_params_file" ought to be treated as > implementation-specific too. The other four files seem essential > to any feature-complete implementation, but is that one?

Re: [HACKERS] GnuTLS support

Peter Eisentraut writes: > Question for the group: We currently have a number of config settings > named ssl_*. Some of these are specific to OpenSSL, some are not, namely: > # general > ssl > ssl_dh_params_file > ssl_cert_file > ssl_key_file > ssl_ca_file >

Re: [HACKERS] GnuTLS support

On 1/2/18 10:35, Peter Eisentraut wrote: > On 11/26/17 20:05, Andreas Karlsson wrote: >> I have now implemented this in the attached patch (plus added support >> for channel binding and rebased it) but I ran into one issue which I >> have not yet solved. The script for the windows version takes

Re: [HACKERS] GnuTLS support

On 1/3/18 04:59, Michael Paquier wrote: > On Tue, Jan 02, 2018 at 10:54:29PM -0500, Peter Eisentraut wrote: >> I think the solution is that we need to require that all SSL server-side >> implementations support all channel binding types. > > That could be a stop for Windows and macos SSL

Re: [HACKERS] GnuTLS support

On Tue, Jan 02, 2018 at 10:54:29PM -0500, Peter Eisentraut wrote: > I think the solution is that we need to require that all SSL server-side > implementations support all channel binding types. That could be a stop for Windows and macos SSL implementations then. I would think that we would

Re: [HACKERS] GnuTLS support

On 1/2/18 18:35, Michael Paquier wrote: > On Tue, Jan 02, 2018 at 10:35:16AM -0500, Peter Eisentraut wrote: >> I see a potential problem with the SCRAM channel binding support. >> GnuTLS will not support tls-server-endpoint, so we'll need to check what >> happens when a client requests that.

Re: [HACKERS] GnuTLS support

On Tue, Jan 02, 2018 at 10:35:16AM -0500, Peter Eisentraut wrote: > I see a potential problem with the SCRAM channel binding support. > GnuTLS will not support tls-server-endpoint, so we'll need to check what > happens when a client requests that. (That's not the problem of this > patch,

Re: [HACKERS] GnuTLS support

On 11/26/17 20:05, Andreas Karlsson wrote: > I have now implemented this in the attached patch (plus added support > for channel binding and rebased it) but I ran into one issue which I > have not yet solved. The script for the windows version takes the > --with-openssl= switch so that cannot

Re: [HACKERS] GnuTLS support

On 11/28/2017 04:19 PM, Peter Eisentraut wrote: On 11/19/17 20:56, Michael Paquier wrote: --with-ssl=(openssl|gnutls) I'm not sure whether this is a great improvement. Why upset existing build and packaging scripts? The usual options style is --with-nameoflib. We can have separate

Re: [HACKERS] GnuTLS support

On 11/19/17 20:56, Michael Paquier wrote: >> If I get it right we ignore gnutls and use openssl (as it's the first >> checked in #ifdefs). Shouldn't we enforce in configure that only one TLS >> implementation is enabled? Either by some elaborate check, or by >> switching to something like >> >>

Re: [HACKERS] GnuTLS support

On Mon, Nov 27, 2017 at 2:37 PM, Michael Paquier wrote: > On Mon, Nov 27, 2017 at 10:28 AM, Andreas Karlsson wrote: >> Hm, after reading more of our MSVC code it seems like building with MSVC >> does not really use switch, people rather have to

Re: [HACKERS] GnuTLS support

On Mon, Nov 27, 2017 at 10:28 AM, Andreas Karlsson wrote: > Hm, after reading more of our MSVC code it seems like building with MSVC > does not really use switch, people rather have to create a config.pl. Is > that correct? The MSVC scripts also seems to only support uuid-ossp

Re: [HACKERS] GnuTLS support

On 11/27/2017 02:20 AM, Michael Paquier wrote: On Mon, Nov 27, 2017 at 10:05 AM, Andreas Karlsson wrote: The script for the windows version takes the --with-openssl= switch so that cannot just be translated to a single --with-ssl switch. Should to have both --with-openssl

Re: [HACKERS] GnuTLS support

On Mon, Nov 27, 2017 at 10:05 AM, Andreas Karlsson wrote: > The script for the windows version takes the > --with-openssl= switch so that cannot just be translated to a single > --with-ssl switch. Should to have both --with-openssl and --with-gnutls or >

Re: [HACKERS] GnuTLS support

Hi, On 11/02/2017 11:33 PM, Andreas Karlsson wrote: > On 09/18/2017 07:04 PM, Jeff Janes wrote:> You fixed the first issue, > but I still get the second one: >> >> be-secure-gnutls.c: In function 'get_peer_certificate': >> be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared >>