On Thu, Dec 03, 2020 at 10:58:39PM +0100, Daniel Gustafsson wrote:
> This version looks good to me, and builds/tests without any issues. While I
> didn't try to adapt the libnss patch to the resowner machinery, I don't see
> any
> reasons off the cuff why it wouldn't work with the scaffolding pro
> On 3 Dec 2020, at 02:47, Michael Paquier wrote:
>
> On Wed, Dec 02, 2020 at 12:03:49PM +0900, Michael Paquier wrote:
>> Thanks. 0001 has been applied and the buildfarm does not complain, so
>> it looks like we are good (I'll take care of any issues, like the one
>> Fujii-san has just reported)
On Wed, Dec 02, 2020 at 12:03:49PM +0900, Michael Paquier wrote:
> Thanks. 0001 has been applied and the buildfarm does not complain, so
> it looks like we are good (I'll take care of any issues, like the one
> Fujii-san has just reported). Attached are new patches for 0002, the
> EVP switch. On
On Tue, Dec 01, 2020 at 10:10:45AM +0100, Daniel Gustafsson wrote:
> That sounds like it would work. Since the cryptohash implementation owns and
> controls the void *data contents it can store whatever it needs to properly
> free it.
That seems to work properly. I have injected some elog(ERROR)
> On 1 Dec 2020, at 06:38, Michael Paquier wrote:
>
> On Mon, Nov 30, 2020 at 02:29:29PM +0100, Daniel Gustafsson wrote:
>> Yeah, that's along the lines of what I was thinking of.
>
> Hmm. I have looked at that, and thought first about having directly a
> reference to the resowner directly in p
On Mon, Nov 30, 2020 at 02:29:29PM +0100, Daniel Gustafsson wrote:
> Yeah, that's along the lines of what I was thinking of.
Hmm. I have looked at that, and thought first about having directly a
reference to the resowner directly in pg_cryptohash_ctx, but that's
not a good plan for two reasons:
-
> On 30 Nov 2020, at 14:13, Michael Paquier wrote:
> On Mon, Nov 30, 2020 at 01:43:24PM +0100, Daniel Gustafsson wrote:
>> Since the cryptohash support is now generalized behind an abstraction layer,
>> wouldn't it make sense to roll the resource ownership there as well kind of
>> like how JIT is
On Mon, Nov 30, 2020 at 01:43:24PM +0100, Daniel Gustafsson wrote:
> Looks good, nothing major sticks out.
Thanks for the review.
> I'm not excited about all the allocations needed here now, but it
> seems the only option.
Yeah, OpenSSL forces a bit our hand here I am afraid..
> Some of these
> On 24 Nov 2020, at 11:52, Michael Paquier wrote:
> I got to look at your suggestion, and finished with the attached which
> is pretty close my previous set, except that MSVC scripts as well as
> the header includes needed a slight refresh.
Looks good, nothing major sticks out. I'm not excited
On Sat, Nov 21, 2020 at 10:19:42AM +0900, Michael Paquier wrote:
> What you meant and what I meant was slightly different here. I meant
> publishing a header in src/include/common/ that would get installed,
> and I'd rather avoid that. And you mean to have the header for local
> consumption in sr
On Fri, Nov 20, 2020 at 11:17:44PM +0100, Daniel Gustafsson wrote:
> On 20 Nov 2020, at 01:33, Michael Paquier wrote:
>> knowing that we still need to deal with the OOM failure handling
>> and pass down the error to the callers playing with SHA2, it feels
>> like the most consistent API to me for
> On 20 Nov 2020, at 01:33, Michael Paquier wrote:
>> This seems like a complication which brings little benefit since the only
>> real
>> errorcase is OOM in creating the context? The built-in crypto support is
>> designed to never fail, and reading the OpenSSL code the only failure cases
>>
On Thu, Nov 19, 2020 at 02:05:35PM +0100, Daniel Gustafsson wrote:
> IIUC, this patchset moves the allocation of the context inside the API rather
> than having the caller be responsible for providing the memory (and thus be
> able to use the stack). This in turn changes the API to returning int r
> On 13 Nov 2020, at 04:14, Michael Paquier wrote:
> I got to think more about this stuff and attached is a new patch set
> that redesigns the generic interface used for the crypto hash
> functions
I've spent some time on this, and the gist of the patchset is clearly something
we want to do: mov
On Thu, Nov 05, 2020 at 03:41:23PM +0900, Michael Paquier wrote:
> This conflicted on HEAD with pgcrypto. Please find attached a rebased
> set.
I got to think more about this stuff and attached is a new patch set
that redesigns the generic interface used for the crypto hash
functions, in order to
On Thu, Oct 15, 2020 at 03:56:21PM +0900, Michael Paquier wrote:
> I got my hands on that, and this proves to simplify a lot things. In
> bonus, attached is a 0003 that cleans up some code in pgcrypto so as
> it uses the in-core resowner facility to handle EVP contexts.
This conflicted on HEAD wi
On Wed, Oct 14, 2020 at 05:18:51PM +0900, Michael Paquier wrote:
> Sure, thanks. I wanted to keep things isolated in sha2_openssl.c as
> that's something specific to the implementation. Thinking more about
> it, your suggestion makes a lot of sense in the long-term by including
> MD5 and HMAC in
On Wed, Oct 14, 2020 at 10:40:12AM +0300, Heikki Linnakangas wrote:
> Since this is going to be core backend code (and also frontend), we don't
> need to use the generic reource owner callback mechanism, we could add a
> built-in ResourceOwnerData field and functions in resowner.c. The callback
> m
On 14/10/2020 06:29, Michael Paquier wrote:
With 0001 in place, switching the SHA2 implementation of OpenSSL to
use EVP is straight-forward, as the only thing that's actually needed
here is to put in place a callback to clean up the EVP contexts
allocated by OpenSSL. This is rather similar to wh
On Mon, Sep 28, 2020 at 12:55:06PM +0900, Michael Paquier wrote:
> Thanks. I have done more tests with the range of OpenSSL versions we
> support on HEAD, and applied this one. I have noticed that the
> previous patch forgot two fail-and-abort code paths as of
> EVP_DigestInit_ex() and EVP_Digest
On Fri, Sep 25, 2020 at 12:27:03AM -0400, Tom Lane wrote:
> Given the tiny number of complaints to date, it seems sufficient to me
> to deal with this in HEAD.
Thanks. I have done more tests with the range of OpenSSL versions we
support on HEAD, and applied this one. I have noticed that the
prev
FIPS only specifies which algorithms are approved for use on it. For instance,
MD-5 is NOT approved at all under FIPS. I would say any algorithm should
produce the same result regardless of where it is run. BTW, on Redhat servers,
the first algorithm listed for use with SSH is MD-5. This causes
On Fri, Sep 25, 2020 at 03:38:22PM -0400, John Scalia wrote:
> Bruce,
>
> In my experience, any client is permitted to connect to FIPS140-2 compliant
> server. I set this up when I worked at SSA, at management’s request.
My question is whether the hash output would match if using different
code
Bruce,
In my experience, any client is permitted to connect to FIPS140-2 compliant
server. I set this up when I worked at SSA, at management’s request.
—
Jay
Sent from my iPad
> On Sep 25, 2020, at 3:13 PM, Bruce Momjian wrote:
>
> On Fri, Sep 25, 2020 at 03:56:53PM +0900, Michael Paquier w
On Fri, Sep 25, 2020 at 03:56:53PM +0900, Michael Paquier wrote:
> On Fri, Sep 25, 2020 at 01:36:44AM -0400, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> However, again, the SCRAM
> >> implementation would already appear to fail that requirement because it
> >> uses a custom HMAC implementa
On Fri, Sep 25, 2020 at 01:36:44AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
>> However, again, the SCRAM
>> implementation would already appear to fail that requirement because it
>> uses a custom HMAC implementation, and HMAC is listed in FIPS 140-2 as a
>> covered algorithm.
>
> Ugh
Peter Eisentraut writes:
> On 2020-09-24 21:44, Daniel Gustafsson wrote:
>> Correct, IIUC in order to be FIPS compliant all cryptographic modules used
>> must
>> be FIPS certified.
> As I read FIPS 140-2, it just specifies what must be true of
> cryptographic modules that claim to follow that s
On 2020-09-24 21:44, Daniel Gustafsson wrote:
On 24 Sep 2020, at 21:22, Robert Haas wrote:
On Thu, Sep 24, 2020 at 1:57 PM Peter Eisentraut
wrote:
Depends on what one considers to be covered by FIPS. The entire rest of
SCRAM is custom code, so running it on top of the world's greatest
SHA-25
Michael Paquier writes:
> On Fri, Sep 25, 2020 at 12:19:44PM +0900, Michael Paquier wrote:
>> Even if we'd try to force our internal implementation of SHA256 on
>> already-released branches instead of the one of OpenSSL, this would be
>> an ABI break for compiled modules expected to work on this r
On Fri, Sep 25, 2020 at 12:19:44PM +0900, Michael Paquier wrote:
> Even if we'd try to force our internal implementation of SHA256 on
> already-released branches instead of the one of OpenSSL, this would be
> an ABI break for compiled modules expected to work on this released
> branch as OpenSSL's
On Thu, Sep 24, 2020 at 09:44:57PM +0200, Daniel Gustafsson wrote:
> On 24 Sep 2020, at 21:22, Robert Haas wrote:
>> I mean, the issue here, as is so often the case, is not what is
>> actually more secure, but what meets the terms of some security
>> standard.
>
> Correct, IIUC in order to be FIP
On Thu, Sep 24, 2020 at 06:28:25PM +0200, Daniel Gustafsson wrote:
> Doh, of course, I blame a lack of caffeine this afternoon. Having a private
> local sha256 implementation using the EVP_* API inside scram-common would
> maintain FIPS compliance and ABI compatibility, but would also be rather ug
> On 24 Sep 2020, at 21:22, Robert Haas wrote:
>
> On Thu, Sep 24, 2020 at 1:57 PM Peter Eisentraut
> wrote:
>> Depends on what one considers to be covered by FIPS. The entire rest of
>> SCRAM is custom code, so running it on top of the world's greatest
>> SHA-256 implementation isn't going to
On Thu, Sep 24, 2020 at 1:57 PM Peter Eisentraut
wrote:
> Depends on what one considers to be covered by FIPS. The entire rest of
> SCRAM is custom code, so running it on top of the world's greatest
> SHA-256 implementation isn't going to make the end product any more
> trustworthy.
I mean, the
On 2020-09-24 18:21, Heikki Linnakangas wrote:
That would technically work, but wouldn't it make the product as whole
not FIPS compliant? I'm not a FIPS lawyer, but as I understand it the
point of FIPS is that all the crypto code is encapsulated in a certified
module. Having your own SHA-256 impl
> On 24 Sep 2020, at 18:21, Heikki Linnakangas wrote:
>
> On 24/09/2020 17:21, Daniel Gustafsson wrote:
>> If we really want to support it (which would require more evidence of it
>> being
>> a problem IMO), using the non-OpenSSL sha256 code would be one option I
>> guess?
>
> That would techn
On 24/09/2020 17:21, Daniel Gustafsson wrote:
If we really want to support it (which would require more evidence of it being
a problem IMO), using the non-OpenSSL sha256 code would be one option I guess?
That would technically work, but wouldn't it make the product as whole
not FIPS compliant?
> On 24 Sep 2020, at 04:53, Michael Paquier wrote:
> Enabling FIPS with OpenSSL 1.0.2 causes direct calls to the SHAXXX
> routines to fail:
> "Low level API call to digest SHA256 forbidden in fips mode"
Confirmed by running 1.0.2s-fips with fips_mode=yes in the alg_section in
openssl.cnf.
> Thi
Hi all,
Enabling FIPS with OpenSSL 1.0.2 causes direct calls to the SHAXXX
routines to fail:
"Low level API call to digest SHA256 forbidden in fips mode"
This got discussed back in 2018, but I never got back to it:
https://www.postgresql.org/message-id/20180911030250.ga27...@paquier.xyz
One thin
39 matches
Mail list logo
