On Wed, 2021-11-24 at 14:03 -0500, Tom Lane wrote:
> > I don't buy the idea that, because we have fixed that particular
> > vulnerability, we've rendered this entire class of bugs "hypothetical".
> > There will be more code and more clients. There will always be bugs.
> > I'd rather the bugs that people write be in places that are less
> > security-critical.
>
> Unless we actively remove the existing way of starting SSL encryption
> --- and GSS encryption, and anything else somebody proposes in future ---
> we are not going to be able to design out this class of bugs.
_We_ can't. I get that. But if this feature is introduced, new clients
will begin to have the option of designing it out of their code. And
DBAs will have the option of locking down their servers so that any new
bugs we introduce in the TLS-upgrade codepath will simply not affect
them.
The ecosystem has the option of transitioning faster than we can. And
then, some number of releases later, an entirely new conversation might
happen. (Or it might not.)
> Maybe
> we could start the process now in the hopes of making such a breaking
> change ten years down the road; but whether anyone will remember to
> pull the trigger then is doubtful, and even if we do remember, you can
> be dead certain it will still break some people's clients.
I am familiar with the "we didn't plant a tree 20 years ago, so we
shouldn't plant one now" line of argument. :D I hope it's not as
persuasive as it used to be.
> So I don't
> put much stock in the argument that this will make things more secure.
> (Ten years from now, SSL may be dead and replaced by something more
> secure against quantum computers.)
That would be great! But I suspect that if that happens, the new
argument will be "we can't upgrade our server to XQuantum-only! Look at
all these legacy SSL clients."
--Jacob