> On 12 Dec 2024, at 12:07, Peter Eisentraut <pe...@eisentraut.org> wrote: > > On 09.12.24 22:37, Daniel Gustafsson wrote: >>> On 9 Dec 2024, at 15:11, Joe Conway <m...@joeconway.com> wrote: >>> >>> On 12/9/24 07:23, Daniel Gustafsson wrote: >>>>> On 4 Dec 2024, at 16:57, Joe Conway <m...@joeconway.com> wrote: >>>>> I can send you the source RPM for openssl 1.1.1c which was an earlier >>>>> FIPS validated version, but the main FIPS patch contains: >>>> AFAICT the forks of 1.1.1 which offer FIPS certification all patch the >>>> common >>>> OpenSSL API FIPS_mode() rather than invent a new one, so the earlier >>>> approach >>>> should work fine. PFA an updated version which I propose we go ahead with. >>> >>> That sounds correct from my memory of it. >>> >>> I have not done any actual testing (yet), but on quick scan this part looks >>> suspicious: >> Not only suspicious but plain wrong, fixed in the attached, thanks! > > I think these function names are wrong: > > + <varname>pgcrypto.legacy_crypto_enabled</varname> determines if the > + built in legacy crypto functions <literal>pg_gen_salt</literal>, > + <literal>pg_gen_salt_rounds</literal>, and <literal>pg_crypt</literal> > + are available for use. > > Those are the C-level functions. The SQL-level functions are called gen_salt > and crypt.
Nice catch, they have been copied around since v1 of the patch without anyone noticing. Fixed, and I also added parentheses to match the docs page in question (<function>crypt()</function> instead of <function>crypt</function>). -- Daniel Gustafsson
v6-0001-pgcrypto-Make-it-possible-to-disable-built-in-cry.patch
Description: Binary data
