On Mon, Feb 19, 2018 at 08:43:44AM -0500, Peter Eisentraut wrote: > I also noticed while working on some SSL code that we have perfectly > good SHA-2 functionality in the server already, but it has no test > coverage outside the SCRAM tests.
Yep, the refactoring in src/common/ has been done for SCRAM. As The first versions of the patch were for SCRAM-SHA-1, only SHA-1 functions were moved. With SCRAM-SHA-256, the full set of APIs for 256, 386 and 512 has been moved as they share much code. > So I suggest these patches that expose the new functions sha224(), > sha256(), sha384(), sha512(). That allows us to make the SSL and SCRAM > tests more robust, and it will allow them to be used in general purpose > contexts over md5(). Huge +1 as well. This also makes sure that the non-SSL implementation carried in Postgres is consistent what what OpenSSL has. This would matter as well if new SSL implementations are added in the future. + <entry><literal>sha224('abc')</literal></entry> + <entry><literal>\x23097d223405d8228642a477bda2​55b32aadbce4bda0b3f7e36c9da7</literal></entry> Some bytea characters from the hash are not able to show up correctly? This does not result in spaces. + Note that for historic reasons, the function <function>md5</function> + returns a hex-encoded value of type <type>text</type> whereas the SHA-2 + functions return type <type>bytea</type>. Use the functions + <function>encode</function> and <function>decode</function> to convert + between the two. Adding an example would be nice. varlena.c is already large and messy. I would suggest to split into a new file all the user-facing cryptographic functions, including md5 and hex functions, say in src/backend/utils/adt/crypt.c. -- Michael
Description: PGP signature