Re: Post-CVE Wishlist

On Wed, Nov 24, 2021 at 1:29 PM Jacob Champion <pchampion@vmware.com> wrote:
> What I'm trying to convince you of is that this pattern of beginning a
> TLS conversation is known to be particularly error-prone, across
> multiple protocols and implementations. I think this is supported by
> the fact that at least three independent client libraries made changes
> in response to this Postgres CVE, a decade after the first writeup of
> this exact vulnerability.
>
> - https://github.com/postgres/postgres/commit/160c0258802
> - https://github.com/pgbouncer/pgbouncer/commit/e4453c9151a
> - https://github.com/yandex/odyssey/commit/4e00bf797a

Sure, that's certainly true, but there are many programming patterns
that have well-known gotchas, and people still write programs that do
those things, debug them, and are satisfied with the results.
Beginning programming classes often cover the abuse of recursion using
fact() and fib() as examples. It's extremely easy to write a program
that concates a large number of strings with O(n^2) runtime, and tons
of people must have made that mistake. I've personally written fork()
bombs multiple times, sometimes unintentionally. None of that proves
that computing factorials or fibonacci numbers, concatenating strings,
or calling fork() are things that you just should not do. However, if
you do those things and make the classic errors, somebody's probably
going to think that you're kind of stupid. So here.

I think it would take an overwhelming amount of evidence to convince
the project to remove support for the current method. One or even two
or three high-severity bugs will probably not convince the project to
do more than spend more studying that code and trying to tighten
things up in a systematic way. Even if we did agree to move away from
it, we would mostly likely add support for the replacement method now
with a view to deprecating the old way in 6-10 years when existing
releases are out of support, which means we'd still need to fix all of
the bugs in the existing implementation, or at least all of the ones
discovered between now and then. The bar for actually ripping it out
on an expedited time scale would be proving not only that it's broken
in multiple ways, but that it's so badly broken that it can't be fixed
with any reasonable amount of effort. And I just don't see one bug
that had a pretty localized fix is really moving the needle as far as
that burden of proof is concerned.

And if the existing method is not going away, then adding a new method
just means that we have two things that can have bugs instead of one.
That might or might not be an advancement in usability or convenience,
but it certainly can't be less buggy.

--
Robert Haas
EDB: http://www.enterprisedb.com