From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Subject: | Re: Proposed patch for key managment |
Date: | 2020-12-18 01:01:22 |
Message-ID: | X9v/Yo8sLB/GKLvt@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote:
> On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote:
>> I don't think there's any need for us to implement a fallback
>> implementation of AES. I'm not entirely sure we need it for hashes
>> but since we've already got it...
We need fallback implementations for cryptohashes (MD5, SHA1/2) and
HMAC because we have SCRAM authentication, pgcrypto and SQL functions
that should be able to work even when not building with any SSL
libraries. So that's here to stay to ensure compatibility with what
we do. All this stuff is already in the tree for ages, it was just
not shaped for a more centralized reuse.
> Agreed. I think there is serious risk we would do AES in a different
> way than OpenSSL, especially if I did it. ;-) We can add a native AES
> one day if we want, but as stated by Michael Paquier, it has to be
> tested so we are sure it returns exactly the same values as OpenSSL.
I think that it would be good to put some generalization here, and
look at options that are offered by other SSL libraries, like libnss
so as we don't finish with a design that restricts the use of a given
feature only to OpenSSL.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-12-18 01:18:45 | Re: Minor documentation error regarding streaming replication protocol |
Previous Message | Michael Paquier | 2020-12-18 00:55:33 | Re: multi-install PostgresNode |