Re: Proposed patch for key managment - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Proposed patch for key managment |
Date | |
Msg-id | 20201205033245.GB8757@momjian.us Whole thread Raw |
In response to | Re: Proposed patch for key managment (Michael Paquier <michael@paquier.xyz>) |
Responses |
Re: Proposed patch for key managment
|
List | pgsql-hackers |
On Sat, Dec 5, 2020 at 11:39:18AM +0900, Michael Paquier wrote: > On Fri, Dec 04, 2020 at 09:08:03PM -0500, Bruce Momjian wrote: > > Here is an updated patch to handle the new hash API introduced by > > commit 87ae9691d2. > > + if (!ossl_initialized) > + { > +#ifdef HAVE_OPENSSL_INIT_SSL > + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL); > +#else > + OPENSSL_config(NULL); > + SSL_library_init(); > + SSL_load_error_strings(); > +#endif > + ossl_initialized = true; > This is a duplicate of what's done in be-secure-openssl.c, and it does > not strike me as a good idea to do that potentially twice. Yeah, I kind of wondered about that. In fact, the code from the original patch would not compile so I got this init code from somewhere else. I have now removed it and it works fine. :-) > git diff --check complains. Uh, can you be more specific? I don't see any output from that command. > +extern bool pg_HMAC_SHA512(const uint8 *key, > + const uint8 *in, int inlen, > + uint8 *out); > I think that the split done in this patch makes the HMAC handling in > the core code messier: > - SCRAM makes use of HMAC internally, and we should try to use the > HMAC of OpenSSL if building with it even for SCRAM. > - For the first reason, I think that we should also have a fallback > implementation. > - This API layer should not depend directly on the SHA2 used (SCRAM > uses SHA256 with HMAC). > FWIW, I got plans to work on that once I am done with the business > around MD5 and OpenSSL. Uh, I just kind of kept all that code and didn't modify it. It would be great if you can help me improve it. I will be using the hash code for the command-line tool that alters the passphrase, so having that in common/ does help me. > The refactoring done with the ciphers moved from pgcrypto to > src/common/ should be a separate patch. In short, it would be good to Uh, I am kind of unclear exactly what was done there since I just took that part of the patch unchanged. > rework this patch and split it into pieces that are independently > useful. This would make the review much easier as well. I can break out the -R/file descriptor passing part as a separate patch, and have the ssl_passphrase_command use that, but that's the only part I know can be useful on its own. Since the patch is large, I found a way to push the branch to git and how to make a download link that tracks whatever I push to the 'key' branch on my github account. Here is the updated patch link: https://github.com/postgres/postgres/compare/master...bmomjian:key.diff -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
pgsql-hackers by date: