On Tue, Apr 26, 2022 at 03:15:24PM +0200, Daniel Gustafsson wrote:
> On 26 Apr 2022, at 03:55, Michael Paquier wrote:
>> I am a bit annoyed to assume that having only a localized
>> ERR_clear_error() in the error code path of the init() call is the
>> only problem that would occur, only because th
> On 26 Apr 2022, at 03:55, Michael Paquier wrote:
>
> On Tue, Apr 26, 2022 at 12:07:32AM +0200, Daniel Gustafsson wrote:
>> In this particular codepath I think we can afford clearing it on the way out,
>> with a comment explaining why. It's easily reproducible and adding a call
>> and
>> a com
On Tue, Apr 26, 2022 at 12:07:32AM +0200, Daniel Gustafsson wrote:
> In this particular codepath I think we can afford clearing it on the way out,
> with a comment explaining why. It's easily reproducible and adding a call and
> a comment is a good documentation for ourselves of this OpenSSL behav
Daniel Gustafsson writes:
> In this particular codepath I think we can afford clearing it on the way out,
> with a comment explaining why.
Yeah. It seems out of the ordinary for an OpenSSL call to stack
two error conditions, so treating a known case of that specially
seems reasonable. Patches s
> On 25 Apr 2022, at 02:50, Michael Paquier wrote:
> On Sat, Apr 23, 2022 at 11:40:19PM +0200, Daniel Gustafsson wrote:
>> On 22 Apr 2022, at 19:01, Tom Lane wrote:
>>> It seems like that solution means you're leaving an extra error in the
>>> queue to
>>> break unrelated code. Wouldn't it be
On Sat, Apr 23, 2022 at 11:40:19PM +0200, Daniel Gustafsson wrote:
> On 22 Apr 2022, at 19:01, Tom Lane wrote:
>> Daniel Gustafsson writes:
>>> Consuming all (both) errors and creating a concatenated string seems
>>> overkill
>>> as it would alter the API from a const error string to something t
> On 22 Apr 2022, at 19:01, Tom Lane wrote:
> Daniel Gustafsson writes:
>> 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
Daniel Gustafsson 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 overk
In trying out an OpenSSL 3.1 build with FIPS enabled I realized that our
cryptohash code had a small issue. Calling a banned cipher generated two
different error messages interleaved:
postgres=# select md5('foo');
ERROR: could not compute MD5 hash: unsupported
postgres=# select md5('foo');
