I happened to notice that if compiled --with-gssapi, 9.6's
contrib/pgcrypto tests report memory stomps for some SHA operations.
Both MEMORY_CONTEXT_CHECKING and valgrind agree there's a problem,
though nothing crashes; it appears that the buffer overrun
only extends into alignment padding, at least on 64-bit hardware.
Investigation found that pgcrypto's references to SHA224_Init
et al were being captured by the system OpenSSL library, which
of course has slightly incompatible definitions of those functions.
We long ago noticed this problem with respect to the sibling
functions SHA256_Init and so on, and commit 56f44784f introduced
renaming macros to dodge the problem for those. However, it didn't
cover the SHA224 family because we didn't use that at the time.
When commit 1abf76e82 added those awhile later, it neglected to add
a similar renaming macro. Better late than never, so do so now.
This appears to affect all branches 8.2 - 9.6, so it's surprising
nobody noticed before now. Maybe the effect is somehow specific
to the way RHEL8 intertwines its GSS and SSL libraries? Anyway,
we refactored all this stuff in v10, so newer branches don't have
the problem.
Few cleanups and couple of new things:
- add SHA2 algorithm to older OpenSSL
- add BIGNUM math to have public-key cryptography work on non-OpenSSL
build.
- gen_random_bytes() function
The status of SHA2 algoritms and public-key encryption can now be
changed to 'always available.'
That makes pgcrypto functionally complete and unless there will be new
editions of AES, SHA2 or OpenPGP standards, there is no major changes
planned.
versions of OpenSSL. If your OpenSSL does not contain SHA2, then there
should be no conflict. But ofcourse, if someone upgrades OpenSSL,
server starts crashing.
Backpatched to 8.1.X.
Marko Kreen
