On 1/24/25 08:55, Daniel Gustafsson wrote:
On 23 Jan 2025, at 21:42, Joe Conway wrote:
LGTM
After staring at it a bit more and fixing a few small details I committed this.
\o/
Thanks for getting this over the finish line!
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databa
> On 23 Jan 2025, at 21:42, Joe Conway wrote:
> LGTM
After staring at it a bit more and fixing a few small details I committed this.
--
Daniel Gustafsson
On 1/22/25 17:49, Daniel Gustafsson wrote:
On 22 Jan 2025, at 19:59, Joe Conway wrote:
I found it necessary to add:
#include
in
contrib/pgcrypto/openssl.c
to avoid a symbol not defined warning.
Makes sense, it doesn't reproduce in my tree but reading OpenSSL code it seems
very plausible
> On 22 Jan 2025, at 19:59, Joe Conway wrote:
> I found it necessary to add:
> #include
> in
> contrib/pgcrypto/openssl.c
> to avoid a symbol not defined warning.
Makes sense, it doesn't reproduce in my tree but reading OpenSSL code it seems
very plausible (and clearly happens in your environ
On 1/21/25 17:57, Daniel Gustafsson wrote:
On 21 Jan 2025, at 22:13, Joe Conway wrote:
I think this is a non-issue. Every implementation I have seen, the OS-level
enabling of FIPS mode is just a way to ensure openssl is automatically put into
FIPS mode when the library is loaded, just as if
> On 21 Jan 2025, at 22:13, Joe Conway wrote:
> I think this is a non-issue. Every implementation I have seen, the OS-level
> enabling of FIPS mode is just a way to ensure openssl is automatically put
> into FIPS mode when the library is loaded, just as if (and not depending on)
> the applicat
On 1/21/25 15:59, Tom Lane wrote:
Daniel Gustafsson writes:
It could indeed be useful, but I doubt we can make it portable to check for
anything but the state of OpenSSL. If the operating system has a FIPS mode
then we won't capture that. That might not be a problem since if the OS is in
FIPS
Daniel Gustafsson writes:
> It could indeed be useful, but I doubt we can make it portable to check for
> anything but the state of OpenSSL. If the operating system has a FIPS mode
> then we won't capture that. That might not be a problem since if the OS is in
> FIPS mode then OpenSSL most likel
> On 21 Jan 2025, at 21:59, Tom Lane wrote:
> (If we end up inventing a FIPS-mode flag, I would fully expect
> interested vendors to patch our code to force it on when the
> OS-level flag is set, which is exactly what they will have done
> to OpenSSL. We should design our behavior with that in m
> On 21 Jan 2025, at 18:51, Joe Conway wrote:
> On 1/21/25 06:39, Daniel Gustafsson wrote:
>> If we add such an alternative output we also need the other case where FIPS
>> is
>> disabled and the functions work, which means we add no test coverage at all
>> as
>> both options are allowed to pas
On 1/21/25 06:39, Daniel Gustafsson wrote:
On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu)
wrote:
Thank you for moving this discussion forward.
Maybe we could document that the test should fail if fips is enabled?
FWIW I have not tested at all on a fips enabled machine. I will see about
> On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu)
> wrote:
>
> Thank you for moving this discussion forward.
>
>> Maybe we could document that the test should fail if fips is enabled?
>>
>> FWIW I have not tested at all on a fips enabled machine. I will see about
>> doing
>> that...
> I t
On 2025-Jan-15, Daniel Gustafsson wrote:
> > On 14 Jan 2025, at 13:12, Hayato Kuroda (Fujitsu)
> > wrote:
> > Also: I'm not sure whether we should bump the version of pgcrypto.
> > It should be done when the API is changed, but the patch does not
> > do. Thought?
>
> I don't think this constit
> On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu)
> wrote:
>
> Thank you for moving this discussion forward.
>
>> Maybe we could document that the test should fail if fips is enabled?
>>
>> FWIW I have not tested at all on a fips enabled machine. I will see about
>> doing
>> that...
> I t
Thank you for moving this discussion forward.
> Maybe we could document that the test should fail if fips is enabled?
>
> FWIW I have not tested at all on a fips enabled machine. I will see about
> doing
> that...
I tested all on a fips enabled machine and test failed.
Since all tests have been
On 1/15/25 09:24, Daniel Gustafsson wrote:
On 14 Jan 2025, at 13:12, Hayato Kuroda (Fujitsu)
wrote:
Similar with [1], `pg_gen_salt_rounds` is not an SQL function.
I think we do not have to mention the function because it's just another
implementation of gen_salt().
Also, use instead of .
> On 14 Jan 2025, at 13:12, Hayato Kuroda (Fujitsu)
> wrote:
> Similar with [1], `pg_gen_salt_rounds` is not an SQL function.
> I think we do not have to mention the function because it's just another
> implementation of gen_salt().
> Also, use instead of .
Fixed.
> I think we must call Mark
Dear Daniel,
Thanks for working on the project. I have few cosmetic comments.
```
+ built in legacy crypto functions gen_salt(),
```
According to other lines, `gen_salt()` should be
`gen_salt()`.
```
+ pg_gen_salt_rounds(), and crypt()
```
Similar with [1], `pg_gen_salt_rounds` is n
Circling back to wrap up this thread I retested with, and without, OpenSSL FIPS
and tweaked the docs and code a little to ensure it detects the right function
to use. The attached is what I propose we go ahead with.
--
Daniel Gustafsson
v7-0001-pgcrypto-Make-it-possible-to-disable-built-in-cry
> On 12 Dec 2024, at 12:07, Peter Eisentraut wrote:
>
> On 09.12.24 22:37, Daniel Gustafsson wrote:
>>> On 9 Dec 2024, at 15:11, Joe Conway wrote:
>>>
>>> On 12/9/24 07:23, Daniel Gustafsson wrote:
> On 4 Dec 2024, at 16:57, Joe Conway wrote:
> I can send you the source RPM for opens
On 09.12.24 22:37, Daniel Gustafsson wrote:
On 9 Dec 2024, at 15:11, Joe Conway wrote:
On 12/9/24 07:23, Daniel Gustafsson wrote:
On 4 Dec 2024, at 16:57, Joe Conway 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 c
> On 9 Dec 2024, at 15:11, Joe Conway wrote:
>
> On 12/9/24 07:23, Daniel Gustafsson wrote:
>>> On 4 Dec 2024, at 16:57, Joe Conway 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
On 12/9/24 07:23, Daniel Gustafsson wrote:
On 4 Dec 2024, at 16:57, Joe Conway 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 commo
> On 4 Dec 2024, at 16:57, Joe Conway 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 inve
> On 3 Dec 2024, at 22:56, Daniel Gustafsson wrote:
>
>> On 3 Dec 2024, at 15:04, Joe Conway wrote:
>>
>> On 12/3/24 08:59, Daniel Gustafsson wrote:
On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
>>> Any other opinions or should we proceed with the proposed GUC?
>>
>> I'm good with i
On 12/4/24 10:57, Joe Conway wrote:
On 12/4/24 10:01, Daniel Gustafsson wrote:
On 4 Dec 2024, at 15:52, Joe Conway wrote:
On 12/4/24 09:45, Daniel Gustafsson wrote:
On 4 Dec 2024, at 15:40, Joe Conway wrote:
On 12/4/24 09:33, Daniel Gustafsson wrote:
since OpenSSL 1.1.1 cannot operate in FI
On 12/4/24 10:01, Daniel Gustafsson wrote:
On 4 Dec 2024, at 15:52, Joe Conway wrote:
On 12/4/24 09:45, Daniel Gustafsson wrote:
On 4 Dec 2024, at 15:40, Joe Conway wrote:
On 12/4/24 09:33, Daniel Gustafsson wrote:
since OpenSSL 1.1.1 cannot operate in FIPS mode.
I don't think that is corre
> On 4 Dec 2024, at 15:52, Joe Conway wrote:
>
> On 12/4/24 09:45, Daniel Gustafsson wrote:
>>> On 4 Dec 2024, at 15:40, Joe Conway wrote:
>>> On 12/4/24 09:33, Daniel Gustafsson wrote:
since OpenSSL 1.1.1 cannot operate in FIPS mode.
>>> I don't think that is correct. The RHEL 8 openssl wh
On 12/4/24 09:45, Daniel Gustafsson wrote:
On 4 Dec 2024, at 15:40, Joe Conway wrote:
On 12/4/24 09:33, Daniel Gustafsson wrote:
since OpenSSL 1.1.1 cannot operate in FIPS mode.
I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2
validated is 1.1.1k. See:
https://csrc.ni
> On 4 Dec 2024, at 15:40, Joe Conway wrote:
>
> On 12/4/24 09:33, Daniel Gustafsson wrote:
>> since OpenSSL 1.1.1 cannot operate in FIPS mode.
>
> I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2
> validated is 1.1.1k. See:
>
> https://csrc.nist.gov/CSRC/media/projects/c
On 12/4/24 09:33, Daniel Gustafsson wrote:
since OpenSSL 1.1.1 cannot operate in FIPS mode.
I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2
validated is 1.1.1k. See:
https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-po
On Wed, Dec 4, 2024 at 9:33 AM Daniel Gustafsson wrote:
> > The comment suggests to me that if the user happened to be using
> > OpenSSL 1.1.1 and CheckLegacyCryptoMode() was called, the expected
> > outcome would be an error, but it will just return.
>
> I think I know what you mean, but just to
On Wed, Dec 4, 2024 at 8:54 AM Daniel Gustafsson wrote:
> Looking over this again I realized it's a bit silly to fall back on
> FIPS_mode()
> when EVP_default_properties_is_fips_enabled isn't available since that would
> only be OpenSSL versions before 3.0 (and since we don't support 1.0.2 then n
> On 4 Dec 2024, at 15:28, Robert Haas wrote:
>
> On Wed, Dec 4, 2024 at 8:54 AM Daniel Gustafsson wrote:
>> Looking over this again I realized it's a bit silly to fall back on
>> FIPS_mode()
>> when EVP_default_properties_is_fips_enabled isn't available since that would
>> only be OpenSSL vers
> On 3 Dec 2024, at 15:04, Joe Conway wrote:
>
> On 12/3/24 08:59, Daniel Gustafsson wrote:
>>> On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
>> Any other opinions or should we proceed with the proposed GUC?
>
> I'm good with it. Did you want to commit or would you rather I do it?
No worr
On 12/3/24 08:59, Daniel Gustafsson wrote:
On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
Any other opinions or should we proceed with the proposed GUC?
I'm good with it. Did you want to commit or would you rather I do it?
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Data
> On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
Any other opinions or should we proceed with the proposed GUC?
--
Daniel Gustafsson
> On 23 Nov 2024, at 17:13, Joe Conway wrote:
> I do wonder if the GUC should be PGC_POSTMASTER (as I had suggested it ought
> to be in an earlier post) rather than PGC_SUSET (which was the way my posted
> patch had it). But perhaps PGC_SUSET is sufficient, and it makes testing
> easier.
I co
On 11/22/24 09:11, Daniel Gustafsson wrote:
On 21 Nov 2024, at 22:39, Joe Conway wrote:
I mean, perhaps I am misreading and/or interpreting all of that differently to
you, but from my reading of the entire thread there was clearly no consensus to
using openssl to provide those two functions
On Thu, Nov 21, 2024 at 4:39 PM Joe Conway wrote:
> I mean, perhaps I am misreading and/or interpreting all of that
> differently to you, but from my reading of the entire thread there was
> clearly no consensus to using openssl to provide those two functions.
OK, I see the problem now. I don't i
> On 21 Nov 2024, at 22:39, Joe Conway wrote:
> I mean, perhaps I am misreading and/or interpreting all of that differently
> to you, but from my reading of the entire thread there was clearly no
> consensus to using openssl to provide those two functions.
My interpretation (or perhaps, my opi
On 11/21/24 15:43, Robert Haas wrote:
On Thu, Nov 21, 2024 at 2:06 PM Joe Conway wrote:
Because that idea was rejected earlier in the thread by multiple people
other than me?
¯\_(ツ)_/¯
I actually don't see that in the thread anywhere. Which messages are
you talking about?
Well there is
On Thu, Nov 21, 2024 at 2:06 PM Joe Conway wrote:
> Because that idea was rejected earlier in the thread by multiple people
> other than me?
>
>¯\_(ツ)_/¯
I actually don't see that in the thread anywhere. Which messages are
you talking about?
--
Robert Haas
EDB: http://www.enterprisedb.com
On 11/20/24 12:14, Daniel Gustafsson wrote:
On 19 Nov 2024, at 18:30, Joe Conway wrote:
Any other opinions out there?
Couldn't installations who would be satisfied with a GUC gate revoke privileges
from the relevant functions already today and achieve almost the same result?
I think that
On 11/19/24 18:12, Robert Haas wrote:
On Tue, Nov 19, 2024 at 12:30 PM Joe Conway wrote:
Any other opinions out there?
Why should we accept your patch (which adds a legacy_crypto_enabled
GUC) instead of adopting the approach originally proposed (i.e. use
the OpenSSL version of the functions)?
> On 19 Nov 2024, at 18:30, Joe Conway wrote:
> Any other opinions out there?
Couldn't installations who would be satisfied with a GUC gate revoke privileges
from the relevant functions already today and achieve almost the same result?
--
Daniel Gustafsson
On 10/29/24 10:08, Daniel Gustafsson wrote:
On 29 Oct 2024, at 13:53, Joe Conway wrote:
On 10/29/24 05:57, Daniel Gustafsson wrote:
On 26 Oct 2024, at 20:10, Joe Conway wrote:
Rather than depend on figuring out if we are in FIPS_mode in a
portable way, I think the GUC is simpler and suffici
On Tue, Nov 19, 2024 at 12:30 PM Joe Conway wrote:
> Any other opinions out there?
Why should we accept your patch (which adds a legacy_crypto_enabled
GUC) instead of adopting the approach originally proposed (i.e. use
the OpenSSL version of the functions)? It seems to me that the two
proposals a
On 10/29/24 12:52, Jacob Champion wrote:
On Sat, Oct 26, 2024 at 11:10 AM Joe Conway wrote:
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
On Sat, Oct 26, 2024 at 11:10 AM Joe Conway wrote:
> 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
> On 29 Oct 2024, at 13:53, Joe Conway wrote:
>
> On 10/29/24 05:57, Daniel Gustafsson wrote:
>>> On 26 Oct 2024, at 20:10, Joe Conway wrote:
>>> 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
On 10/29/24 05:57, Daniel Gustafsson wrote:
On 26 Oct 2024, at 20:10, Joe Conway wrote:
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
> On 26 Oct 2024, at 20:10, Joe Conway wrote:
> 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
On 20 Feb 2024, at 13:40, Peter Eisentraut 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 patch
> On 20 Feb 2024, at 13:40, Peter Eisentraut 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
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
> On 20 Feb 2024, at 13:24, Robert Haas wrote:
>
> On Tue, Feb 20, 2024 at 5:09 PM 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 pal
On 20.02.24 12:27, Robert Haas wrote:
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 t
On Tue, Feb 20, 2024 at 5:09 PM 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.
That
> On 20 Feb 2024, at 12:18, Peter Eisentraut wrote:
> I think we are going about this the wrong way. It doesn't make sense to ask
> OpenSSL what a piece of code that doesn't use OpenSSL should do.
Given that pgcrypto cannot be built without OpenSSL, and ideally we should be
using the OpenSSL i
> On 20 Feb 2024, at 12:27, Robert Haas wrote:
>
> On Tue, Feb 20, 2024 at 4:49 PM Peter Eisentraut 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 exten
On Tue, Feb 20, 2024 at 4:49 PM Peter Eisentraut 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
On 20.02.24 11:09, Daniel Gustafsson wrote:
On 20 Feb 2024, at 10:56, Koshi Shibagaki (Fujitsu)
wrote:
Let me confirm the discussion in threads. I think there are two topics.
1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
cipher (crypt-bf, etc...) in crypt() and
> On 20 Feb 2024, at 10:56, Koshi Shibagaki (Fujitsu)
> wrote:
> Let me confirm the discussion in threads. I think there are two topics.
> 1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
> cipher (crypt-bf, etc...) in crypt() and gen_salt()
That level might be over
Let me confirm the discussion in threads. I think there are two topics.
1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
cipher (crypt-bf, etc...) in crypt() and gen_salt()
2. adding new "crypt-aes" module.
If this is correct, I would like to make a patch for the first
> On 16 Feb 2024, at 15:49, Peter Eisentraut wrote:
> Like, if we did a "crypt-aes", would that be FIPS-compliant? I don't know.
If I remember my FIPS correct: Only if it used a FIPS certified implementation,
like the one in OpenSSL when the fips provider has been loaded. The cipher
must be al
On 16.02.24 14:30, Daniel Gustafsson wrote:
On 16 Feb 2024, at 13:57, Peter Eisentraut wrote:
On 16.02.24 10:16, Daniel Gustafsson wrote:
2. The crypt() and gen_salt() methods built on top of them (modes of operation,
kind of) are not FIPS-compliant.
I wonder if it's worth trying to make pgc
> On 16 Feb 2024, at 13:57, Peter Eisentraut wrote:
>
> On 16.02.24 10:16, Daniel Gustafsson wrote:
>>> 2. The crypt() and gen_salt() methods built on top of them (modes of
>>> operation, kind of) are not FIPS-compliant.
>> I wonder if it's worth trying to make pgcrypto disallow non-FIPS complia
On 16.02.24 10:16, Daniel Gustafsson wrote:
2. The crypt() and gen_salt() methods built on top of them (modes of operation,
kind of) are not FIPS-compliant.
I wonder if it's worth trying to make pgcrypto disallow non-FIPS compliant
ciphers when the compiled against OpenSSL is running with FIPS
On 2/16/24 04:16, Daniel Gustafsson wrote:
On 15 Feb 2024, at 16:49, Peter Eisentraut wrote:
1. All the block ciphers currently supported by crypt() and gen_salt() are not
FIPS-compliant.
2. The crypt() and gen_salt() methods built on top of them (modes of operation,
kind of) are not FIPS-
Dear Daniel
Thanks for your reply.
> I wonder if it's worth trying to make pgcrypto disallow non-FIPS compliant
> ciphers when the compiled against OpenSSL is running with FIPS mode
> enabled, or raise a WARNING when used? It seems rather unlikely that
> someone running OpenSSL with FIPS=yes wan
Dear Peter
Thanks for the replying
> 1. All the block ciphers currently supported by crypt() and gen_salt() are not
> FIPS-compliant.
>
> 2. The crypt() and gen_salt() methods built on top of them (modes of
> operation,
> kind of) are not FIPS-compliant.
>
> 3. The implementations (crypt-blowfi
> On 15 Feb 2024, at 16:49, Peter Eisentraut wrote:
> 1. All the block ciphers currently supported by crypt() and gen_salt() are
> not FIPS-compliant.
>
> 2. The crypt() and gen_salt() methods built on top of them (modes of
> operation, kind of) are not FIPS-compliant.
I wonder if it's worth
On 15.02.24 13:42, Koshi Shibagaki (Fujitsu) wrote:
However, crypt() and gen_salt() do not use OpenSSL as mentioned in [2].
Therefore, if we run crypt() and gen_salt() on a machine with FIPS mode enabled,
they are not affected by FIPS mode. This means we can use encryption algorithms
disallowed i
Hi
This is Shibagaki.
When FIPS mode is enabled, some encryption algorithms cannot be used.
Since PostgreSQL15, pgcrypto requires OpenSSL[1], digest() and other functions
also follow this policy.
However, crypt() and gen_salt() do not use OpenSSL as mentioned in [2].
Therefore, if we run crypt()
75 matches
Mail list logo
