On Sat, Dec 8, 2012 at 11:07 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> As there hasn't been any new input since this comment I am marking the
> patch as "Rejected" in the CF application.
Sounds good. FWIW, even if we were going to accept this, I can't
imagine back-patching it. Users will come after us with pitchforks if
we change something like this in a minor release, and for good reason.This could utterly break working applications in
afashion that
requires code changes and a recompile to fix. That is not a nice kind
of thing for a shared library to do as part of a security/bug fix
update.
If you ask me, the problem here is that OpenSSL's error-reporting
mechanism is just plain badly designed. I remember programming in
BASIC back in the 80s and thinking to myself: what kind of a stupid
error-handling interface is ON ERROR GOTO? And can I pummel the
person who came up with it? This is basically a throwback to that
sort of design, where your error-handlers get to guess where exactly
the program was when the exception happened. You can make it work if
you try hard enough, but you sure have to try hard. Frankly, I don't
have a lot of hope of making things a whole lot better here no matter
what we do. FWICS, this kind of problem is endemic in OpenSSL, which
also doesn't seem to believe in comprehensive documentation or code
comments. It would be nice if we had an API to some other, less
crappy encryption library; or maybe even some generic API that lets
you easily wire it into any library you happen to wish to use.
Not that I'm volunteering to write the patch... :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company