On Fri, Apr 19, 2024 at 4:00 PM Tom Lane wrote:
> Thomas Munro writes:
> > Probably not this thread's fault, but following the breadcrumbs to the
> > last thread to touch the relevant test lines in
> > authentication/001_password, is it expected that we have these
> > warnings?
>
> > psql::1:
Thomas Munro writes:
> Probably not this thread's fault, but following the breadcrumbs to the
> last thread to touch the relevant test lines in
> authentication/001_password, is it expected that we have these
> warnings?
> psql::1: WARNING: roles created by regression test cases
> should have
On Sat, Nov 18, 2023 at 7:46 AM Peter Eisentraut wrote:
> All done, thanks.
Probably not this thread's fault, but following the breadcrumbs to the
last thread to touch the relevant test lines in
authentication/001_password, is it expected that we have these
warnings?
psql::1: WARNING: roles
On 15.11.23 21:29, Tom Lane wrote:
Daniel Gustafsson writes:
Since the 3DES/DES deprecations aren't limited to FIPS, do we want to do
anything for pgcrypto where we have DES/3DES encryption? Maybe a doc patch
which mentions the deprecation with a link to the SP could be in order?
A docs
pgp_sym_encrypt('Secret.', 'key', 's2k-digest-algo=sha1'),
'key', 'expect-s2k-digest-algo=sha1');
From 8feace1abca7aad6b9a9a58f464d571649e2d1e2 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 5 Oct 2023 14:45:35 +0200
Subject: [PATCH v4 3/5] Allow tests to pass in OpenSSL FIPS mo
> On 15 Nov 2023, at 12:44, Peter Eisentraut wrote:
>
> On 15.11.23 00:07, Tom Lane wrote:
>> I'm more concerned about the 3DES situation. Fedora might be a bit
>> ahead of the curve here, but according to the link above, everybody is
>> supposed to be in compliance by the end of 2023. So I'd
On 15.11.23 00:07, Tom Lane wrote:
I'm more concerned about the 3DES situation. Fedora might be a bit
ahead of the curve here, but according to the link above, everybody is
supposed to be in compliance by the end of 2023. So I'd be inclined
to guess that the 3DES-is-rejected case is going to
> On 15 Nov 2023, at 00:07, Tom Lane wrote:
> (In reality, people running FIPS mode are probably pretty
> accustomed to seeing this error, so maybe it's not worth the
> trouble to improve it.)
In my experience this holds a lot of truth, this is a common error pattern and
while all improvements
Peter Eisentraut writes:
> On 05.10.23 22:55, Tom Lane wrote:
>> I found another bit of fun we'll need to deal with: on my F38
>> platform, pgcrypto/3des fails as attached. Some googling finds
>> this relevant info:
>> https://github.com/pyca/cryptography/issues/6875
>> That is, FIPS deprecation
On 05.10.23 22:55, Tom Lane wrote:
I found another bit of fun we'll need to deal with: on my F38
platform, pgcrypto/3des fails as attached. Some googling finds
this relevant info:
https://github.com/pyca/cryptography/issues/6875
That is, FIPS deprecation of 3DES is happening even as we speak.
On 05.10.23 22:55, Tom Lane wrote:
I found another bit of fun we'll need to deal with: on my F38
platform, pgcrypto/3des fails as attached. Some googling finds
this relevant info:
https://github.com/pyca/cryptography/issues/6875
That is, FIPS deprecation of 3DES is happening even as we speak.
On 05.10.23 22:04, Tom Lane wrote:
On the way to testing this, I discovered that we have a usability
regression with recent OpenSSL releases. The Fedora 35 installation
I used to use for testing FIPS-mode behavior would produce errors like
+ERROR: could not compute MD5 hash: disabled for
I found another bit of fun we'll need to deal with: on my F38
platform, pgcrypto/3des fails as attached. Some googling finds
this relevant info:
https://github.com/pyca/cryptography/issues/6875
That is, FIPS deprecation of 3DES is happening even as we speak.
So apparently we'll have little
Peter Eisentraut writes:
> Continuing this, we have fixed many issues since. Here is a patch set
> to fix all remaining issues.
On the way to testing this, I discovered that we have a usability
regression with recent OpenSSL releases. The Fedora 35 installation
I used to use for testing
ing issues.
>
> v4-0001-citext-Allow-tests-to-pass-in-OpenSSL-FIPS-mode.patch
> v4-0002-pgcrypto-Allow-tests-to-pass-in-OpenSSL-FIPS-mode.patch
+ERROR: crypt(3) returned NULL
Not within scope here, but I wish we had a better error message here. That's
for another patch though clea
-mode.patch
These two are pretty straightforward.
v4-0003-Allow-tests-to-pass-in-OpenSSL-FIPS-mode-TAP-test.patch
This one does some delicate surgery and could use some thorough review.
v4-0004-Allow-tests-to-pass-in-OpenSSL-FIPS-mode-rest.patch
This just adds alternative expected files
> On 13 Mar 2023, at 11:06, Peter Eisentraut
> wrote:
> On 06.03.23 17:06, Daniel Gustafsson wrote:
>> fipshash() with an explanatory comments sounds like a good idea.
>
> committed like that
+1. Looks like there is a just a slight diff in the compression.sql test suite.
--
Daniel Gustafsson
On 06.03.23 17:06, Daniel Gustafsson wrote:
On 6 Mar 2023, at 15:55, Tom Lane wrote:
Daniel Gustafsson writes:
For readers without all context, wouldn't it be better to encode in the
function name why we're not just calling a hash like md5? Something like
fips_allowed_hash() or similar?
On Thu, Mar 09, 2023 at 10:01:14AM +0100, Peter Eisentraut wrote:
> I have fixed these comments to match cryptohash_openssl.c.
Missed that, thanks for the fix.
--
Michael
signature.asc
Description: PGP signature
On 08.03.23 10:37, Daniel Gustafsson wrote:
The comment in question was missed in 55fe26a4b58, but I agree that it's a
false claim given the OpenSSL implementation so removing or at least mimicking
the comments in cryptohash_openssl.c would be better.
I have fixed these comments to match
> On 8 Mar 2023, at 10:30, Peter Eisentraut
> wrote:
>
> On 08.03.23 10:21, Daniel Gustafsson wrote:
>>> On 8 Mar 2023, at 09:49, Peter Eisentraut
>>> wrote:
>>> It occurred to me that it would be easier to maintain this in the long run
>>> if we could enable a "fake FIPS" mode that would
On 08.03.23 10:21, Daniel Gustafsson wrote:
On 8 Mar 2023, at 09:49, Peter Eisentraut
wrote:
It occurred to me that it would be easier to maintain this in the long run if we could
enable a "fake FIPS" mode that would have the same effect but didn't require
fiddling with the OpenSSL
On 06.03.23 17:06, Daniel Gustafsson wrote:
fipshash() with an explanatory comments sounds like a good idea.
I think that name would be quite false advertising.
On 08.03.23 08:40, Tom Lane wrote:
Peter Eisentraut writes:
On 05.03.23 00:04, Tom Lane wrote:
I've gone through this and have a modest suggestion: let's invent some
wrapper functions around encode(sha256()) to reduce the cosmetic diffs
and consequent need for closer study of patch changes.
> On 8 Mar 2023, at 09:49, Peter Eisentraut
> wrote:
> It occurred to me that it would be easier to maintain this in the long run if
> we could enable a "fake FIPS" mode that would have the same effect but didn't
> require fiddling with the OpenSSL configuration or installation.
>
> The
On 09.12.22 05:16, Michael Paquier wrote:
On Wed, Dec 07, 2022 at 03:14:09PM +0100, Peter Eisentraut wrote:
Here is the next step. To contain the scope, I focused on just "make check"
for now. This patch removes all incidental calls to md5(), replacing them
with sha256(), so that they'd pass
Peter Eisentraut writes:
> On 05.03.23 00:04, Tom Lane wrote:
>> I've gone through this and have a modest suggestion: let's invent some
>> wrapper functions around encode(sha256()) to reduce the cosmetic diffs
>> and consequent need for closer study of patch changes. In the attached
>> I called
On 05.03.23 00:04, Tom Lane wrote:
I've gone through this and have a modest suggestion: let's invent some
wrapper functions around encode(sha256()) to reduce the cosmetic diffs
and consequent need for closer study of patch changes. In the attached
I called them "notmd5()", but I'm surely not
> On 6 Mar 2023, at 15:55, Tom Lane wrote:
> Daniel Gustafsson writes:
>> For readers without all context, wouldn't it be better to encode in the
>> function name why we're not just calling a hash like md5? Something like
>> fips_allowed_hash() or similar?
>
> I'd prefer shorter than that ---
Daniel Gustafsson writes:
>> On 5 Mar 2023, at 00:04, Tom Lane wrote:
>> I've gone through this and have a modest suggestion: let's invent some
>> wrapper functions around encode(sha256()) to reduce the cosmetic diffs
>> and consequent need for closer study of patch changes. In the attached
>>
> On 5 Mar 2023, at 00:04, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> [ v2-0001-Remove-incidental-md5-function-uses-from-main-reg.patch ]
>
> I've gone through this and have a modest suggestion: let's invent some
> wrapper functions around encode(sha256()) to reduce the cosmetic diffs
>
Peter Eisentraut writes:
> [ v2-0001-Remove-incidental-md5-function-uses-from-main-reg.patch ]
I've gone through this and have a modest suggestion: let's invent some
wrapper functions around encode(sha256()) to reduce the cosmetic diffs
and consequent need for closer study of patch changes. In
On 28.02.23 06:01, Michael Paquier wrote:
On Mon, Feb 27, 2023 at 08:23:34AM +0100, Peter Eisentraut wrote:
On 27.02.23 08:16, Michael Paquier wrote:
This refers to brin_minmax_multi_distance_macaddr8(), no? This is
amazing. I have a hard time imagining how FIPS would interact with
what we
On Mon, Feb 27, 2023 at 08:23:34AM +0100, Peter Eisentraut wrote:
> On 27.02.23 08:16, Michael Paquier wrote:
>> This refers to brin_minmax_multi_distance_macaddr8(), no? This is
>> amazing. I have a hard time imagining how FIPS would interact with
>> what we do in mac8.c to explain that, so it
On 27.02.23 08:16, Michael Paquier wrote:
On Thu, Oct 13, 2022 at 01:16:18PM +0200, Alvaro Herrera wrote:
However, there are some changes in brin_multi.out that are quite
surprising and suggest that we might have bugs in brin:
+WARNING: unexpected number of results 31 for
On Thu, Oct 13, 2022 at 01:16:18PM +0200, Alvaro Herrera wrote:
> However, there are some changes in brin_multi.out that are quite
> surprising and suggest that we might have bugs in brin:
>
> +WARNING: unexpected number of results 31 for
> (macaddr8col,>,macaddr8,b1:d1:0e:7b:af:a4:42:12,33)
>
On 09.12.22 05:16, Michael Paquier wrote:
Some tests inspect the actual md5 result strings or build statistics based
on them. I have tried to carefully preserve the meaning of the original
tests, to the extent that they could be inferred, in some cases adjusting
example values by matching the
On Wed, Dec 07, 2022 at 03:14:09PM +0100, Peter Eisentraut wrote:
> Here is the next step. To contain the scope, I focused on just "make check"
> for now. This patch removes all incidental calls to md5(), replacing them
> with sha256(), so that they'd pass with or without FIPS mode. (Two tests
On 13.10.22 12:26, Peter Eisentraut wrote:
I think that the other md5() computations done in the main regression
test suite could just be switched to use one of the sha*() functions
as they just want to put their hands on text values. It looks like a
few of them have some expections with the
On 2022-Oct-13, Peter Eisentraut wrote:
> Right, that's the rest of my original patch. I'll come back with an updated
> version of that.
However, there are some changes in brin_multi.out that are quite
surprising and suggest that we might have bugs in brin:
+WARNING: unexpected number of
On 12.10.22 03:18, Michael Paquier wrote:
On Tue, Oct 11, 2022 at 01:51:50PM +0200, Peter Eisentraut wrote:
Let's make a small start on this. The attached patch moves the tests of the
md5() function to a separate test file. That would ultimately make it
easier to maintain a variant expected
On Tue, Oct 11, 2022 at 01:51:50PM +0200, Peter Eisentraut wrote:
> Let's make a small start on this. The attached patch moves the tests of the
> md5() function to a separate test file. That would ultimately make it
> easier to maintain a variant expected file for FIPS mode where that function
>
On 04.10.22 17:45, Peter Eisentraut wrote:
While working on the column encryption patch, I wanted to check that
what is implemented also works in OpenSSL FIPS mode. I tried running
the normal test suites after switching the OpenSSL installation to FIPS
mode, but that failed all over the
43 matches
Mail list logo
