Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

>> On 20 Feb 2024, at 13:40, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> On 20.02.24 12:39, Daniel Gustafsson wrote:
>>> A fifth option is to throw away our in-tree implementations and use the OpenSSL
>>> API's for everything, which is where this thread started. If the effort to
>>> payoff ratio is palatable to anyone then patches are for sure welcome.
>> The problem is that, as I understand it, these crypt routines are
>> not designed in a way that you can just plug in a crypto library
>> underneath. Effectively, the definition of what, say, blowfish
>> crypt does, is whatever is in that source file, and transitively,
>> whatever OpenBSD does.

Someone asked me about this issue a few days ago which led me back to
this unresolved thread.

> diff --git a/contrib/pgcrypto/pgcrypto.c b/contrib/pgcrypto/pgcrypto.c
> index 96447c5757..3d4391ebe1 100644
> --- a/contrib/pgcrypto/pgcrypto.c
> +++ b/contrib/pgcrypto/pgcrypto.c
> @@ -187,6 +187,14 @@ pg_crypt(PG_FUNCTION_ARGS)
> *resbuf;
> text *res;
>
> +#if defined FIPS_mode
> + if (FIPS_mode())
> +#else
> + if (EVP_default_properties_is_fips_enabled(OSSL_LIB_CTX_get0_global_default()))
> +#endif
> + ereport(ERROR,
> + (errmsg("not available when using OpenSSL in FIPS mode")));
> +
> buf0 = text_to_cstring(arg0);
> buf1 = text_to_cstring(arg1);
>
>
> Greenplum implemented similar functionality but with a GUC, fips_mode=<bool>.
> The problem with that is that it gives the illusion that enabling such a GUC
> gives any guarantees about FIPS which isn't really the case since postgres
> isn't FIPS certified.

Rather than depend on figuring out if we are in FIPS_mode in a portable
way, I think the GUC is simpler and sufficient. Why not do that and just
use a better name, e.g. legacy_crypto_enabled or something similar
(bike-shedding welcomed) as in the attached.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com