Improve error handling of HMAC computations and SCRAM
От
Michael Paquier
Тема
Improve error handling of HMAC computations and SCRAM
Дата
Msg-id
Yd0N9tSAIIkFd+qi@paquier.xyz
Список
Дерево обсуждения
Improve error handling of HMAC computations and SCRAM Michael Paquier <michael@paquier.xyz>
Re: Improve error handling of HMAC computations and SCRAM Sergey Shinderuk <s.shinderuk@postgrespro.ru>
Re: Improve error handling of HMAC computations and SCRAM Michael Paquier <michael@paquier.xyz>
Re: Improve error handling of HMAC computations and SCRAM Sergey Shinderuk <s.shinderuk@postgrespro.ru>
Re: Improve error handling of HMAC computations and SCRAM Michael Paquier <michael@paquier.xyz>
Re: Improve error handling of HMAC computations and SCRAM Michael Paquier <michael@paquier.xyz>
Re: Improve error handling of HMAC computations and SCRAM Sergey Shinderuk <s.shinderuk@postgrespro.ru>
Re: Improve error handling of HMAC computations and SCRAM Michael Paquier <michael@paquier.xyz>
Re: Improve error handling of HMAC computations and SCRAM Sergey Shinderuk <s.shinderuk@postgrespro.ru>
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
В списке pgsql-hackers по дате отправления