Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Here is a patch that implements "localssl" as well. It is quite simple.
The other area that would need some thought before we could consider
this "done" is the behavior of libpq's sslmode parameter. With the
patch as given, an SSL-capable libpq will *default* to using SSL over
sockets, which might be thought overkill; it is almost certainly
going to result in a performance penalty. Is this a reasonable default
behavior? Should sslmode be extended to allow specification of
different behaviors for sockets vs. TCP
Does the patch handle patched clients connecting to unpatched servers
and vice versa?
I am undecided whether I will use this proposed functionality or not. I
would like to tighten up security (only a few people have access to the
machine, but even a few may be a few too many?). Cryptographic
authentication and encrypted data stream cost is high compared to no
cryptographic authentication or encrypted data streams. I don't know if
it would impact me or not. Peter: Have you tried running a benchmark of
localssl vs localnossl?
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
