On Wed, Nov 24, 2021 at 1:29 PM Jacob Champion <pchamp...@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
