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
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
> >> abstraction
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
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
>> T
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
>
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 binding
> 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 adj
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 for
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.
>
> There
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 wrong
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
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
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 p
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
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 default. But if it
>> do
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 (assumin
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
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 applica
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 certa
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 improve our windows or OS
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 paramet
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. I
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
> >>
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 applicable to GnuTLS, so we might just leave it to die with some
appropriate docume
On 1/27/18 19:49, Bruce Momjian wrote:
> To open another can of worms, are we ever going to rename "ssl"
> parameters to "tls"
I had been thinking about that, too, but it doesn't seem worth it.
While renaming server-side settings might be feasible with some
annoyance, this would also include renam
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 propos
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 ou
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 mo
> 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 to keep
>> the API consiste
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 wil
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
>>> {be,fe}-secure-gnutls.c, and with half an eye on th
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.
>
> Even then, it's not tha
> 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 Transport implementation, I have id
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 more
> areas of refactoring that should be done i
> On 19 Jan 2018, at 19:43, Peter Eisentraut
> wrote:
> 0003-Move-EDH-support-to-common-files.patch
>
> To avoid copy-and-paste, and also because the EDH explanation doesn't
> really belong in a file header comment. Maybe the whole thing is known
> well enough nowadays that we can just remove
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.
Even then, it's not that hard to imagine minor variations between what
different implementati
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 the
Robert Haas writes:
> ... Worse yet, users are
> not going to intrinsically know which SSL implementation was compiled
> into the server they have.
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 t
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 cipher
> suite choice (not sure
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
>> accept
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
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
i
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 are supported by every implementation,
>>
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 to be treated as
> >> implementation-specific too. The
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 to be treated as
>> implementation-specific too. The other four files seem essential
>> to any feature-complete i
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?
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
> ssl_crl_file
> # OpenSSL
> ssl_ciph
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 t
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 implement
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 benefit
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. (That
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, however.)
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 ju
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 options
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
>>
>> --
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 create a config.pl. Is
>> that correct? The MSVC scr
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 which it
> just call
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 and --with-gnutls or
-
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
> --with-ssl=(openssl|gnutls) and --with-ssl-
On 11/20/2017 02:56 AM, Michael Paquier wrote:
On Mon, Nov 20, 2017 at 9:42 AM, Tomas Vondra
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
On Tue, Nov 21, 2017 at 11:45 PM, Andreas Karlsson wrote:
> There is a function called gnutls_session_channel_binding() which seems to
> do something very similar to SSL_get*_finished() which has been in GnuTLS
> since 2.12.
>
> https://www.gnutls.org/manual/gnutls.html#Channel-Bindings
Nice. Thi
On 11/20/2017 02:56 AM, Michael Paquier wrote:
Sorry about that. Something more specific needs to happen here as well
for channel binding support with SCRAM. CheckSCRAMAuth() now assumes
that the channel binding mechanism SCRAM-SHA-256-PLUS can be published
to the client if SSL is used, because O
On Mon, Nov 20, 2017 at 9:42 AM, Tomas Vondra
wrote:
> I don't want to be the annoying guy, but this patch no longer applies
> due to 642bafa0c5f9f08d106a14f31429e0e0c718b603 touching the tests :-(
Sorry about that. Something more specific needs to happen here as well
for channel binding 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
>> (f
64 matches
Mail list logo
