From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Date: Fri, 18 Dec 2020 10:44:46 -0500
Message-ID: <20201218154446.GC28841@momjian.us> (raw)
In-Reply-To: <20201218131853.GA16415@tamriel.snowman.net>
References: <X9hHoQcZ11pBtgnz@paquier.xyz>
<20201215210212.GG14596@momjian.us>
<X9lhi1ht04I+v/rV@paquier.xyz>
<20201216220412.GB4527@momjian.us>
<X9qXuLekePLRYrB2@paquier.xyz>
<20201217163954.GY16415@tamriel.snowman.net>
<20201217171022.GE23260@momjian.us>
<X9v/Yo8sLB/GKLvt@paquier.xyz>
<20201218031414.GA28841@momjian.us>
<20201218131853.GA16415@tamriel.snowman.net>
On Fri, Dec 18, 2020 at 08:18:53AM -0500, Stephen Frost wrote:
> What I would be thinking about with this are really three pieces-
>
> - C API for libpq (not relevant for this, but we have had issues in the
> past with exposing OpenSSL-specific things there)
Right.
> - C API in backend - we should try to at least set up the structure to
> allow multiple encryption implementations, either via different
> libraries or if someone feels it'd be useful to write a built-in
> implementation, but as I mentioned just a moment ago, we aren't going
> to get this perfect and we should accept that.
All my OpenSSL-specific stuff is isolated in src/common.
> - User API - we should avoid having OpenSSL-specific bits exposed to
> users, and I don't think we do today, so I don't think this is an
> issue at the moment.
Right, there is nothing OpenSSL-specific on the user side, but some of
the scripts assume you can pass an open file descriptor to a
PKCS11-enabled tool, and I don't know if non-OpenSSL libraries support
that.
Ideally, we would have scripts for each library to use their
command-line API for this. I am hestitant to rename the scripts to
contain the name openssl because I am unclear if we will ever have
non-OpenSSL implementations of these. I updated the script comments at
the top to indicate "It uses OpenSSL with PKCS11 enabled via OpenSC.".
One point is that the passphrase scripts are useful for cluster file
encryption _and_ unlocking TLS certificates.
> > I split apart my patch to create cipher{_openssl}.c and hmac{_openssl}.c
> > so the single HMAC function is not in the cipher file anymore, attached.
>
> Will try to look at this soon, but in general the idea seems right.
Should I be using the init/update/final HMAC API that SCRAM uses so it
is easier to integrate into Michael's patch? I can do that, but didn't
because that is going to require me to create a much larger footprint in
the main code, and that might be harder to integrate once Michael's API
is final. It is easier for me to change one line to five lines than to
change five lines to five different lines.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, sfrost@snowman.net, michael@paquier.xyz, masahiko.sawada@2ndquadrant.com
Subject: Re: Proposed patch for key managment
In-Reply-To: <20201218154446.GC28841@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox