Re: md5 issues Postgres14 on OL7
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christoph Moench-Tegeder <cmt@burggraben.net>, Michael Mühlbeyer <Michael.Muehlbeyer@trivadis.com>, "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Date: 2022-01-08T06:04:50Z
Lists: pgsql-general
Attachments
- v3-0001-Improve-error-reporting-for-cryptohashes.patch (text/x-diff) patch v3-0001
On Fri, Jan 07, 2022 at 05:40:09PM -0500, Tom Lane wrote:
> Hm, you still have cast-away-const in md5_crypt_verify and
> plain_crypt_verify. Can we adjust their APIs to make them
> return const char * as well (and then their API spec is that
> the caller must never free the string, rather than being
> vague about it)?
Okay. Hmm. This requires a couple of extra const markers in the area
of authentication and SASL for the backend, but not much actually.
I thought first that it would be more invasive.
> The other thing that bothers me slightly is that it looks like
> some code paths could end up passing a NULL string pointer to
> ereport or sprintf, since you don't positively guarantee that
> an error will return a string there. I suppose this is safe
> since 3779ac62d, but I don't really want to start making API
> specs depend on it.
Sounds fair to me in the long term, even for non-assert builds. I
have added a small-ish wrapper routine in crytohash_openssl.c for this
purpose, with a name copied from {be,fe}-secure-openssl.c to ease any
future refactoring lookups if that proves to be worth in the future.
--
Michael
Commits
-
Improve error handling of cryptohash computations
- 3a0cced86d3b 14.2 landed
- b69aba74578a 15.0 landed