Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Fri, Dec 18, 2020 at 08:18:53AM -0500, Stephen Frost wrote:
> > - 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.
... and in 'openssl' files, with 'generic' functions on top, right?
That's what I recall from before and seems like the right approach to at
least start with, and then we likely make adjustments as needed to the
API when we add another encryption library.
> > - 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.
That generally seems alright to me.
> 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.".
I'm not too worried about the specific names of those scripts.
Definitely having comments that indicate what the dependencies are is
certainly good.
> One point is that the passphrase scripts are useful for cluster file
> encryption _and_ unlocking TLS certificates.
That's certainly good.
> > > 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.
For my 2c, ideally we'd get a review done of Michael's changes and just
get that committed and have your work here rebased over that. I don't
see any reason why we can't get that done in relatively short order.
Just because it's registered in the January CF doesn't mean we actually
have to wait for that to get done, it just needs a review from another
committer (or self certification from Michael if he's happy with it).
Thanks,
Stephen
