Thread: pgsql: Refactor MD5 implementations according to new cryptohash infrast
Refactor MD5 implementations according to new cryptohash infrastructure This commit heavily reorganizes the MD5 implementations that exist in the tree in various aspects. First, MD5 is added to the list of options available in cryptohash.c and cryptohash_openssl.c. This means that if building with OpenSSL, EVP is used for MD5 instead of the fallback implementation that Postgres had for ages. With the recent refactoring work for cryptohash functions, this change is straight-forward. If not building with OpenSSL, a fallback implementation internal to src/common/ is used. Second, this reduces the number of MD5 implementations present in the tree from two to one, by moving the KAME implementation from pgcrypto to src/common/, and by removing the implementation that existed in src/common/. KAME was already structured with an init/update/final set of routines by pgcrypto (see original pgcrypto/md5.h) for compatibility with OpenSSL, so moving it to src/common/ has proved to be a straight-forward move, requiring no actual manipulation of the internals of each routine. Some benchmarking has not shown any performance gap between both implementations. Similarly to the fallback implementation used for SHA2, the fallback implementation of MD5 is moved to src/common/md5.c with an internal header called md5_int.h for the init, update and final routines. This gets then consumed by cryptohash.c. The original routines used for MD5-hashed passwords are moved to a separate file called md5_common.c, also in src/common/, aimed at being shared between all MD5 implementations as utility routines to keep compatibility with any code relying on them. Like the SHA2 changes, this commit had its round of tests on both Linux and Windows, across all versions of OpenSSL supported on HEAD, with and even without OpenSSL. Author: Michael Paquier Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20201106073434.GA4961@paquier.xyz Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b67b57a966af0c4a9547ac6fff334d3c256d9c2a Modified Files -------------- contrib/pgcrypto/Makefile | 2 +- contrib/pgcrypto/internal.c | 25 +- contrib/pgcrypto/md5.c | 397 -------------- src/common/Makefile | 3 +- src/common/cryptohash.c | 13 + src/common/cryptohash_openssl.c | 3 + src/common/md5.c | 683 ++++++++++++++----------- src/common/md5_common.c | 149 ++++++ contrib/pgcrypto/md5.h => src/common/md5_int.h | 60 ++- src/include/common/cryptohash.h | 3 +- src/include/common/md5.h | 5 +- src/tools/msvc/Mkvcbuild.pm | 12 +- src/tools/pgindent/typedefs.list | 1 + 13 files changed, 613 insertions(+), 743 deletions(-)
Re: pgsql: Refactor MD5 implementations according to new cryptohash infrast
From
Michael Paquier
Date:
On Thu, Dec 10, 2020 at 03:01:20AM +0000, Michael Paquier wrote: > Refactor MD5 implementations according to new cryptohash infrastructure > > This commit heavily reorganizes the MD5 implementations that exist in > the tree in various aspects. > > First, MD5 is added to the list of options available in cryptohash.c and > cryptohash_openssl.c. This means that if building with OpenSSL, EVP is > used for MD5 instead of the fallback implementation that Postgres had > for ages. With the recent refactoring work for cryptohash functions, > this change is straight-forward. If not building with OpenSSL, a > fallback implementation internal to src/common/ is used. And this has broken uuid-ossp. The switch is quite easy to do as this module just needs to use cryptohash APIs for MD5. Will fix in a minute.. -- Michael
Attachment
Re: pgsql: Refactor MD5 implementations according to new cryptohash infrast
From
Michael Paquier
Date:
On Thu, Dec 10, 2020 at 12:18:57PM +0900, Michael Paquier wrote: > And this has broken uuid-ossp. The switch is quite easy to do as this > module just needs to use cryptohash APIs for MD5. Will fix in a > minute.. So, I have reproduced the failure with --with-uuid=e2fs and now fixed it with 525e60b. FWIW, I got to wonder this morning whether we should have a sha1 option for cryptohash.c, and seeing how ugly is the dependency on md5.c and sha1.c between pgcrypto and uuid-ossp, this may give an extra reason to do so.. -- Michael