Re: Allow tests to pass in OpenSSL FIPS mode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow tests to pass in OpenSSL FIPS mode
Date: 2023-03-04 23:04:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> [ v2-0001-Remove-incidental-md5-function-uses-from-main-reg.patch ]

I've gone through this and have a modest suggestion: let's invent some
wrapper functions around encode(sha256()) to reduce the cosmetic diffs
and consequent need for closer study of patch changes. In the attached
I called them "notmd5()", but I'm surely not wedded to that name.

This also accounts for some relatively recent additions to stats_ext.sql
that introduced yet more uses of md5(). This passes for me on a
FIPS-enabled Fedora system, with the exception of md5.sql and
password.sql. I agree that the right thing for md5.sql is just to add
a variant expected-file. password.sql could perhaps use some refactoring
so that we don't have two large expected-files to manage.

The only other place that perhaps needs discussion is rowsecurity.sql,
which has some surprisingly large changes: not only do the random
strings change, but there are rowcount differences in some results.
I believe this is because there are RLS policy checks and view conditions
that actually examine the contents of the "md5" strings, eg

CREATE POLICY p1 ON s1 USING (a in (select x from s2 where y like '%2f%'));

My recommendation is to just accept those changes as OK and move on.
I doubt that anybody checked the existing results line-by-line either.

So, once we've done something about md5.sql and password.sql, I think
this is committable.

regards, tom lane

Attachment Content-Type Size
v3-0001-Remove-incidental-md5-function-uses-from-main-reg.patch text/x-diff 60.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-03-04 23:21:09 Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Previous Message Dave Cramer 2023-03-04 23:04:22 Re: Request for comment on setting binary format output per session