During the discussion on OpenSSL 3.0.0 support in pgcrypto [0], I
started to wonder whether the "internal" code variants in pgcrypto (the
ones that implement the ciphers themselves instead of using OpenSSL) are
more trouble than they are worth. As discussed there, keeping this adds
some amount of complexity in the code that could otherwise easily be
done away with.
Historically, this made some sense. OpenSSL support and pgcrypto came
into PostgreSQL at around the same time. So it was probably reasonable
for pgcrypto not to rely exclusively on OpenSSL being available. But
today, building PostgreSQL for production without some kind of SSL
support seems rare, and then nevertheless requiring cryptographic
hashing and encryption support from pgcrypto seems unreasonable.
So I'm tempted to suggest that we remove the built-in, non-OpenSSL
cipher and hash implementations in pgcrypto (basically INT_SRCS in
pgcrypto/Makefile), and then also pursue the simplifications in the
OpenSSL code paths described in [0].
Thoughts?
(Some thoughts from those pursuing NSS support would also be useful.)
[0]:
https://www.postgresql.org/message-id/b1a62889-bb45-e5e0-d138-7a370a0a334f@enterprisedb.com