Re: Incorrect allocation handling for cryptohash functions with OpenSSL - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Incorrect allocation handling for cryptohash functions with OpenSSL
Date
Msg-id X+U5B5aTCbe2X1ZM@paquier.xyz
Whole thread Raw
In response to Re: Incorrect allocation handling for cryptohash functions with OpenSSL  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Incorrect allocation handling for cryptohash functions with OpenSSL
List 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

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: In-placre persistance change of a relation
Next
From: Ian Lawrence Barwick
Date:
Subject: Re: Feature request: Connection string parsing for postgres_fdw