On Fri, 23 Jul 1999, Tom Lane wrote:
> 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...
I may be lost here, so forgive me ahead of time...but, if I'm reading
Magnus' email correctly, this just breaks backward compatibility...with
the change, pre-6.6 clients would not be able to talk to a 6.6 server, but
6.7 and 6.6 would be compatible?
If this is correct, I've lost what the problem is here, except that, if
this is the case, such a change shoudl signal a new major number release,
vs just minor...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
