Improve error handling of HMAC computations and SCRAM
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-11T04:56:22Z
Lists: pgsql-hackers
Attachments
- 0001-Improve-HMAC-error-handling.patch (text/x-diff) patch 0001
Hi all, This is a follow-up of the work done in b69aba7 for cryptohashes, but this time for HMAC. The main issue here is related to SCRAM, where we have a lot of code paths that have no idea about what kind of failure is happening when an error happens, and this exists since v10 where SCRAM has been introduced, for some of them, frontend and backend included. \password is one example. The set of errors improved here would only trigger in scenarios that are unlikely going to happen, like an OOM or an internal OpenSSL error. It would be possible to create a HMAC from a MD5, which would cause an error when compiling with OpenSSL and FIPS enabled, but the only callers of the pg_hmac_* routines involve SHA-256 in core through SCRAM, so I don't see much a point in backpatching any of the things proposed here. The attached patch creates a new routine call pg_hmac_error() that one can use to grab details about the error that happened, in the same fashion as what has been done for cryptohashes. The logic is not that complicated, but note that the fallback HMAC implementation relies itself on cryptohashes, so there are cases where we need to look at the error from pg_cryptohash_error() and store it in the HMAC private context. Thoughts? -- Michael
Commits
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 landed
-
Fix incorrect comments in hmac.c and hmac_openssl.c
- 3c1ffd02dd05 14.2 landed
- 87f29f4fcc4e 15.0 landed
-
Fix comment related to pg_cryptohash_error()
- af8d530e4758 14.2 landed
- 9a3d8e188667 15.0 landed