Re: Incorrect allocation handling for cryptohash functions with OpenSSL

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Incorrect allocation handling for cryptohash functions with OpenSSL
Дата
Msg-id X+U5B5aTCbe2X1ZM@paquier.xyz
обсуждение исходный текст
Ответ на Re: Incorrect allocation handling for cryptohash functions with OpenSSL  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Incorrect allocation handling for cryptohash functions with OpenSSL  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: In-placre persistance change of a relation
Следующее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: Feature request: Connection string parsing for postgres_fdw