From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Incorrect allocation handling for cryptohash functions with OpenSSL |
Date: | 2020-12-25 00:57:43 |
Message-ID: | X+U5B5aTCbe2X1ZM@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 21, 2020 at 04:28:26PM -0500, Robert Haas wrote:
> TBH, I think there's no point in return an error here at all, because
> it's totally non-specific. You have no idea what failed, just that
> something failed. Blech. If we want to check that ctx is non-NULL, we
> should do that with an Assert(). Complicating the code with error
> checks that have to be added in multiple places that are far removed
> from where the actual problem was detected stinks.
You could technically do that, but only for the backend at the cost of
painting the code of src/common/ with more #ifdef FRONTEND. Even if
we do that, enforcing an error in the backend could be a problem when
it comes to some code paths. One of them is the SCRAM mock
authentication where we had better generate a generic error message.
Using an Assert() or just letting the code go through is not good
either, as we should avoid incorrect computations or crash on OOM, not
to mention that this would fail the detection of bugs coming directly
from OpenSSL or any other SSL library this code plugs with. In short,
I think that there are more benefits in letting the caller control the
error handling.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lawrence Barwick | 2020-12-25 00:59:09 | Re: Feature request: Connection string parsing for postgres_fdw |
Previous Message | Kyotaro Horiguchi | 2020-12-25 00:12:52 | Re: In-placre persistance change of a relation |