On 01/28/2015 08:05 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
Right, that was the idea. I wanted it to include the word OpenSSL, to
make it clear in the callers that it's specific to OpenSSL. And SSL,
because that's the name of the struct. I agree it looks silly,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
What bothers me about this is that it punts SSL work to the application
and requires that they be coded to work with both OpenSSL and whatever
else we implement (eg: GnuTLS) to do anything but the most simple
On 01/28/2015 06:58 PM, Stephen Frost wrote:
Although I think OpenSSL SSL is a little bit duplicatively
redundant. Why not just OpenSSL?
I wondered also, but figured it was probably because it's OpenSSL's
ssl structure, which then made sense.
Right, that was the idea. I wanted it to include
On Wed, Jan 28, 2015 at 10:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's a patch to implement the above scheme. It adds four functions to
libpq, to interrogate the SSL status:
int PQsslInUse(const PGconn *conn)
Returns true (1) if the connection uses SSL, false (0) if not.
Heikki Linnakangas hlinnakan...@vmware.com writes:
Right, that was the idea. I wanted it to include the word OpenSSL, to
make it clear in the callers that it's specific to OpenSSL. And SSL,
because that's the name of the struct. I agree it looks silly, though.
One idea is to have two
On 08/20/2014 12:58 AM, Heikki Linnakangas wrote:
On 08/19/2014 10:31 PM, Robert Haas wrote:
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert's got a point though: there is always going to be
On Tue, Aug 19, 2014 at 03:26:56PM -0400, Stephen Frost wrote:
I think there's been some improvement since I last had to go through the
pain of setting this all up, and some of it is undoubtably OpenSSL's
fault, but there's definitely quite a bit more we could be doing to make
SSL support
On Tue, Aug 19, 2014 at 03:47:17PM -0400, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
BTW, if we're beating on libpq, I wonder if we shouldn't consider
bumping the soversion at some point. I mean, I know that we
technically don't need to do that if we're only *adding*
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
server_cert_valid: Did the server present a valid certificate?
yes or no
server_cert_matches_host: Does the Common Name of the certificate
match the host connected to? yes or no
Aren't these questions addressed by sslmode?
Exposing
On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
Exposing the SSL information as generic key/value pairs allows
adding more attributes in the future, without breaking the ABI, and
it also allows exposing implementation-specific information in a
generic way. The attributes listed above
On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost sfr...@snowman.net wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
server_cert_valid: Did the server present a valid certificate?
yes or no
server_cert_matches_host: Does the Common Name of the certificate
match the host
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:
[...]
I'm not really sure we need all that. We're not building a general ssl
library abstraction here.
On Tue, Aug 19, 2014 at 5:05 PM, Stephen Frost sfr...@snowman.net wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:
[...]
I'm not really sure we need
* Magnus Hagander (mag...@hagander.net) wrote:
On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost sfr...@snowman.net wrote:
Aren't these questions addressed by sslmode?
Not entirely. You can have sslmode=require and have a matching
certificate. You don't *have* to have sslmode=verify-full for
On 08/19/2014 05:48 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
server_cert_valid: Did the server present a valid certificate?
yes or no
server_cert_matches_host: Does the Common Name of the certificate
match the host connected to? yes or no
Aren't
On 2014-08-19 11:05:07 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
At first blush, I'd say a whole bunch.. Off the top of my head I can
think of:
[...]
I'm not really sure we need all that. We're
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
I think it would be nice to be able to query those attributes
explicitly, rather than just expect libpq to reject the connection
if something's wrong. For example, I'm thinking that an interactive
client might present an annoying pop-up
* Andres Freund (and...@2ndquadrant.com) wrote:
No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to get at
the whole certificate chain in a
On 2014-08-19 11:52:37 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make
Stephen Frost wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Indeed, the ODBC driver only uses libpq for authentication, then
calls PQgetssl(), and takes over the whole show calling SSL_read()
and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
that, but
* Andres Freund (and...@2ndquadrant.com) wrote:
Per Apache's documentation, mod_ssl and mod_gnutls support the same set
of environment variables (with the same names even), so I don't buy this
argument either.
Gnutls is quite similar from what it provides to openssl. That's not
saying
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost wrote:
Yeah, that's what I remembered. There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double
On 08/19/2014 06:44 PM, Stephen Frost wrote:
Hmm. That seems a bit too much. Perhaps provide just the certificate
itself in DER/PEM format, and have the client parse it (using
OpenSSL or something else) if it wants more details.
I really don't care for that approach. Our SSL support has always
On 08/19/2014 07:10 PM, Alvaro Herrera wrote:
Stephen Frost wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Indeed, the ODBC driver only uses libpq for authentication, then
calls PQgetssl(), and takes over the whole show calling SSL_read()
and SSL_write() itself. Ideally, we'd
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Um, libpq has recently gained the ability to return result fragments,
right? Those didn't exist when libpq-ification of odbc was attempted,
as I recall -- perhaps it's possible now.
I was trying to
On 08/19/2014 06:52 PM, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to
On 08/19/2014 06:00 PM, Magnus Hagander wrote:
On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost sfr...@snowman.net wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
server_cert_valid: Did the server present a valid certificate?
yes or no
server_cert_matches_host: Does the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Um, libpq has recently gained the ability to return result fragments,
right? Those didn't exist when libpq-ification of odbc was attempted,
as I recall --
On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
alternative API to get the same information. PQgetSSL() returns a pointer
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas robertmh...@gmail.com wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas robertmh...@gmail.com wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
On 08/19/2014 06:44 PM, Stephen Frost wrote:
Hmm. That seems a bit too much. Perhaps provide just the certificate
itself in DER/PEM format, and have the client parse it (using
OpenSSL or something else) if it wants more details.
I really
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
I think you just packed up the goalposts for a one-way trip to Mars,
but I wonder: What would you consider proper SSL support? What
exactly are we missing?
I hit on a few things in my other email, but there is a huge portion of
SSL which is
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas robertmh...@gmail.com wrote:
I have a hard time believing
* Robert Haas (robertmh...@gmail.com) wrote:
BTW, if we're beating on libpq, I wonder if we shouldn't consider
bumping the soversion at some point. I mean, I know that we
technically don't need to do that if we're only *adding* functions and
not changing any of the existing stuff in
On 08/19/2014 10:31 PM, Robert Haas wrote:
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas
On 2014-08-20 00:58:22 +0300, Heikki Linnakangas wrote:
I don't much like adding a separate function for every SSL implementation,
but you've got a point that it would be nice to make it difficult to call
PQgetSSLstruct() and just assume that the returned struct is e.g an OpenSSL
struct, while
Andres Freund and...@2ndquadrant.com writes:
On 2014-08-20 00:58:22 +0300, Heikki Linnakangas wrote:
I don't much like adding a separate function for every SSL implementation,
but you've got a point that it would be nice to make it difficult to call
PQgetSSLstruct() and just assume that the
On 2014-08-19 19:11:46 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-08-20 00:58:22 +0300, Heikki Linnakangas wrote:
I don't much like adding a separate function for every SSL implementation,
but you've got a point that it would be nice to make it difficult to
On Mon, Aug 18, 2014 at 12:54 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
server_cert_valid: Did the server present a valid certificate? yes or
no
Is this just whether the signature verifies? Or whether the chain is
all verified? Or whether the chain leads to a root in the
41 matches
Mail list logo
