Thread: Patch - SSL back to working

Here is a patch to bring SSL support back working. Sorry for the long delay
:-(

I also added the function sslinfo() to get information about the SSL
connection.
 (I'm not 100% sure I got that one right, though. Is it enough to put an
  entry in pg_proc.h, or do I need it anywhere else?
  Also, I picked "lowest oid in highest free block" - correct?)

Example of the function for non-SSL connection:
template1=# select sslinfo();
            sslinfo
-------------------------------
 SSL not active on connection.
(1 row)

Example of the function for SSL connection:
template1=# select sslinfo();
               sslinfo
-------------------------------------
 SSL cipher: DES-CBC3-SHA, bits: 168
(1 row)


//Magnus

Magnus Hagander <mha@sollentuna.net> writes:
> Here is a patch to bring SSL support back working. Sorry for the long delay
> :-(

This is good ;-)

> I also added the function sslinfo() to get information about the SSL
> connection.

That strikes me as a very bizarre way of doing things.  Why not add an
inquiry function to the libpq API, instead?

            regards, tom lane

On Sat, 19 Aug 2000, Tom Lane wrote:

> Magnus Hagander <mha@sollentuna.net> writes:
> > Here is a patch to bring SSL support back working. Sorry for the long delay
> > :-(
>
> This is good ;-)
>
> > I also added the function sslinfo() to get information about the SSL
> > connection.
>
> That strikes me as a very bizarre way of doing things.  Why not add an
> inquiry function to the libpq API, instead?

what's the difference between 'select sslinfo()' and 'select version()',
or is 'select version()' part of the libpq API also?

The Hermit Hacker <scrappy@hub.org> writes:
>>>> I also added the function sslinfo() to get information about the SSL
>>>> connection.
>>
>> That strikes me as a very bizarre way of doing things.  Why not add an
>> inquiry function to the libpq API, instead?

> what's the difference between 'select sslinfo()' and 'select version()',

Well, (1) backend version is not known directly to libpq; the backend
*must* be queried in some fashion for that info.  I suppose the SSL
connection info is known equally well at both ends of the connection,
so it seems bizarre to inquire of the backend information that would
be available without any round-trip query.

(2) Transport-level info should be available without having to deal with
concerns like whether you have a half-issued query already, or are in
abort transaction state and can't get the backend to execute a SELECT,
etc.  This is a confusion of protocol-stack levels; it's like asking
the backend what the client's IP address is.

(3) version() is a constant, more or less, but sslinfo() will vary
depending on how you have connected.  That bothers me, although I can't
quite put my finger on the reason why.

            regards, tom lane

all good points, thanks :)

On Sat, 19 Aug 2000, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> >>>> I also added the function sslinfo() to get information about the SSL
> >>>> connection.
> >>
> >> That strikes me as a very bizarre way of doing things.  Why not add an
> >> inquiry function to the libpq API, instead?
>
> > what's the difference between 'select sslinfo()' and 'select version()',
>
> Well, (1) backend version is not known directly to libpq; the backend
> *must* be queried in some fashion for that info.  I suppose the SSL
> connection info is known equally well at both ends of the connection,
> so it seems bizarre to inquire of the backend information that would
> be available without any round-trip query.
>
> (2) Transport-level info should be available without having to deal with
> concerns like whether you have a half-issued query already, or are in
> abort transaction state and can't get the backend to execute a SELECT,
> etc.  This is a confusion of protocol-stack levels; it's like asking
> the backend what the client's IP address is.
>
> (3) version() is a constant, more or less, but sslinfo() will vary
> depending on how you have connected.  That bothers me, although I can't
> quite put my finger on the reason why.
>
>             regards, tom lane
>
>

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org