On 01/28/2015 08:05 PM, Tom Lane wrote:
Heikki Linnakangas 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 h
Heikki Linnakangas 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 separate arguments: the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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
> > checks. T
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 i
Stephen Frost 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
> checks. That's a problem because people are *not* going to
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 28, 2015 at 10:13 AM, Heikki Linnakangas
> 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
On Wed, Jan 28, 2015 at 10:13 AM, Heikki Linnakangas
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.
>
> const char *PQss
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 wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane wrote:
Robert's got a point though: there is always going to be somebody who
wants something we fail
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 *a
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 e
On 2014-08-19 19:11:46 -0400, Tom Lane wrote:
> Andres Freund 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
> >> PQge
Andres Freund 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 returned struct is
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, wh
On 08/19/2014 10:31 PM, Robert Haas wrote:
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane wrote:
Magnus Hagander writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas wrote:
I have a hard time believing that something like this will really
* 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 backwa
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander wrote:
> On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just
* 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 whic
* 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.
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas 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
Magnus Hagander writes:
> On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas 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 incredibly thorough in exposing the
>> inf
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
> 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 inform
On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
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
> directly to the OpenSS
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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 i
On 08/19/2014 06:00 PM, Magnus Hagander wrote:
On Tue, Aug 19, 2014 at 4: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 c
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 g
Stephen Frost 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 remember off
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 mod
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 alwa
* 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...),
> > requirin
* 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
> s
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
> > tha
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
* 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 c
* 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
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 t
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"
Ar
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Aug 19, 2014 at 4:48 PM, Stephen Frost 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 that.
>
> How
On Tue, Aug 19, 2014 at 5:05 PM, 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 tha
* 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 4: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 t
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 a
* 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
On Mon, Aug 18, 2014 at 12:54 PM, Heikki Linnakangas
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 directory?
Does it include
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 directly to the OpenSSL private struct, and you can do anything
with that. We cannot h
44 matches
Mail list logo
