On Sat, Dec 8, 2012 at 11:07 AM, Andres Freund <and...@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 a fashion 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
