From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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 15:44:46 |
Message-ID: | 20201218154446.GC28841@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-12-18 15:48:00 | Re: Refactoring HMAC in the core code |
Previous Message | Tom Lane | 2020-12-18 15:10:42 | Re: pgbench failed when -f option contains a char '@' |