Magnus Hagander <mha@sollentuna.net> writes:
> I've now finished "polishing off" my old SSL code, and rewritten it to work
> with 6.6 (current snapshot). Included is the patch against the cvs tree from
> Jul 22nd.
Cool. Secure connections are good.
> Unfortunatly, in order to allow for negotiated SSL, this patch breaks the
> current protocol (meaning old clients will not work with the new server, and
> the other way around). I felt it was better to break this here, than to
> break the frontend API (which would otherwise have been required).
This is *not* cool. Breaking both clients and servers, whether they
actually support SSL or not, is a bit much, don't you think? Especially
when the way you propose to do it makes it impossible for a server to
support both old and new clients: by the time the server finds out the
client's protocol version, it's already done something incompatible
with old clients.
I think there must be some way of signaling SSL support capability
without making a backwards-incompatible change in the startup protocol.
At a minimum an SSL-enabled server must be able to accept connections
from pre-SSL clients.
If nothing better comes to mind, we could have SSL-capable servers
listen at two port addresses, say 5432 for insecure connections and
5433 for secure ones. But there's probably a better way.
BTW, it should be possible for the dbadmin to configure a server to
accept *only* secured connections, perhaps from a subset of users/hosts;
that would take a new column in pg_hba.conf. Didn't look at your patch
closely enough to see if you already did that...
regards, tom lane