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

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

  1. Improve error handling of cryptohash computations