Re: Cryptohash OpenSSL error queue in FIPS enabled builds

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Cryptohash OpenSSL error queue in FIPS enabled builds
Дата
Msg-id 3704258.1650646911@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Cryptohash OpenSSL error queue in FIPS enabled builds  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: Cryptohash OpenSSL error queue in FIPS enabled builds
Список pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
> It turns out that OpenSSL places two errors in the queue for this operation,
> and we only consume one without clearing the queue in between, so we grab an
> error from the previous run.

Ugh.

> Consuming all (both) errors and creating a concatenated string seems overkill
> as it would alter the API from a const error string to something that needs
> freeing etc (also, very few OpenSSL consumers actually drain the queue, OpenSSL
> themselves don't).  Skimming the OpenSSL code I was unable to find another
> example of two errors generated.  The attached calls ERR_clear_error() as how
> we do in libpq in order to avoid consuming earlier errors.

This seems quite messy.  How would clearing the queue *before* creating
the object improve matters?  It seems like that solution means you're
leaving an extra error in the queue to break unrelated code.  Wouldn't
it be better to clear after grabbing the error?  (Or maybe do both.)

Also, a comment seems advisable.

            regards, tom lane



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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup
Следующее
От: Jacek Trocinski
Дата:
Сообщение: Why is EXECUTE granted to PUBLIC for all routines?