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
Attachments:
ssl_patchapplication/octet-stream; name=ssl_patchDownload+130-92
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
Magnus Hagander writes:
Here is a patch to bring SSL support back working. Sorry for the long delay
:-(
Any chance we can get a `diff -cr' patch?
Btw., a while ago I was wondering about the postmaster `-l' option: I
think it should be removed and the job should be done in pg_hba.conf
alone. Instead I would like an option (possibly -l) that turns off SSL
completely. Currently you can't even start the postmaster without the
certificate files etc. (Some docs on how to do that would be nice as
well.)
Btw.2: Where do you get the documenation? I have been looking for SSL API
docs all over.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
(note to self: change signature, you don't live there anymore...)
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?
Well. I did it mostly so I wouldn't have to change the API :-)
But your points are very good :-) I'll add something to the frontend
library, remove the function, and send a new patch.
Peter wrote:
Any chance we can get a `diff -cr' patch?
Sure, I'll do that next time. I just used the 'difforig' script that is
included in the backend. If this is not the preferred format of the patch,
maybe it shuold be updated?
Btw., a while ago I was wondering about the postmaster `-l' option: I
think it should be removed and the job should be done in pg_hba.conf
alone. Instead I would like an option (possibly -l) that turns off SSL
completely. Currently you can't even start the postmaster without the
certificate files etc. (Some docs on how to do that would be nice as
well.)
Hm. Yeah. It's actually handled at both stages right now. You can use the
"-l" option to reject *all* non-SSL INET connections at an early stage,
before even looknig at pg_hba.conf. But everything can be handled in
pg_hba.conf already.
I'll look at fixing that up as well :-)
Btw.2: Where do you get the documenation? I have been looking for SSL API
docs all over.
Actually, nowhere... I got it looking through other programs source when
developnig a "poor mans VPN" solution for work. Then I just took what I had
there and applied to postgresql. There is a serious lack of documentation of
that API...
//Magnus
Import Notes
Resolved by subject fallback
Magnus Hagander writes:
Well. I did it mostly so I wouldn't have to change the API :-)
But your points are very good :-) I'll add something to the frontend
library, remove the function, and send a new patch.
I think something like what PQhost(), PQport(), etc. are doing would be
okay.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden