On Thu, Sep 24, 2020 at 09:44:57PM +0200, Daniel Gustafsson wrote: > On 24 Sep 2020, at 21:22, Robert Haas <robertmh...@gmail.com> wrote: >> I mean, the issue here, as is so often the case, is not what is >> actually more secure, but what meets the terms of some security >> standard. > > Correct, IIUC in order to be FIPS compliant all cryptographic modules used > must > be FIPS certified.
/me whitles, thinking about not using src/common/md5.c when building with OpenSSL to actually get a complain if FIPS gets used. >> At least in the US, FIPS 140-2 compliance is a reasonably >> common need, so if we can make it easier for people who have that need >> to be compliant, they are more likely to use PostgreSQL, which seems >> like something that we should want. > > The proposed patch makes SCRAM+FIPS work for 14, question is if we need/want > to > try and address v10-13. Unfortunately, I don't have a good answer for that, except for the answers involving an ABI breakage. FWIW, the only users of those APIs I can find in the open wild are pgpool, which actually bundles a copy of the code in src/common/ so it does not matter, and pgbouncer, that uses a different compatibility layer to make the code compilable: https://sources.debian.org/src/pgbouncer/1.14.0-1/include/common/postgres_compat.h/?hl=26#L26 But it is not really possible to say if there is any closed code relying on that, so I'd like to fix that just on HEAD, about which I guess there would be no objections? -- Michael
signature.asc
Description: PGP signature
