Re: Replace current implementations in crypt() and gen_salt() to OpenSSL - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Date
Msg-id 0EB81E1E-48E8-4543-9EB0-9FA56020C5BD@yesql.se
Whole thread Raw
In response to Re: Replace current implementations in crypt() and gen_salt() to OpenSSL  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
List pgsql-hackers
> On 20 Feb 2024, at 12:27, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Feb 20, 2024 at 4:49 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> I think there are several less weird ways to address this:
>>
>> * Just document it.
>>
>> * Make a pgcrypto-level GUC setting.
>>
>> * Split out these functions into a separate extension.
>>
>> * Deprecate these functions.
>>
>> Or some combination of these.
>
> I don't think the first two of these proposals help anything. AIUI,
> FIPS mode is supposed to be a system wide toggle that affects
> everything on the machine. The third one might help if you can be
> compliant by just choosing not to install that extension, and the
> fourth one solves the problem by sledgehammer.

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.

> Does Linux provide some way of asking whether "fips=1" was specified
> at kernel boot time?

There is a crypto.fips_enabled sysctl but I have no idea how portable that is
across distributions etc.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: speed up a logical replica setup
Next
From: Daniel Gustafsson
Date:
Subject: Re: Replace current implementations in crypt() and gen_salt() to OpenSSL