Cryptohash OpenSSL error queue in FIPS enabled builds

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Cryptohash OpenSSL error queue in FIPS enabled builds
Date: 2022-04-22 14:56:38
Message-ID: C89D932C-501E-4473-9750-638CFCD9095E@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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');
ERROR: could not compute MD5 hash: initialization error

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.

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.

--
Daniel Gustafsson https://vmware.com/

Attachment Content-Type Size
v1-0001-Clear-the-OpenSSL-error-queue-before-cryptohash-o.patch application/octet-stream 1.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-04-22 15:21:03 Re: [PATCH] Compression dictionaries for JSONB
Previous Message Andrew Dunstan 2022-04-22 14:24:27 Re: pgsql: Allow db.schema.table patterns, but complain about random garbag