Allow tests to pass in OpenSSL FIPS mode
От | Peter Eisentraut |
---|---|
Тема | Allow tests to pass in OpenSSL FIPS mode |
Дата | |
Msg-id | dbbd927f-ef1f-c9a1-4ec6-c759778ac852@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Allow tests to pass in OpenSSL FIPS mode
Re: Allow tests to pass in OpenSSL FIPS mode |
Список | pgsql-hackers |
While working on the column encryption patch, I wanted to check that what is implemented also works in OpenSSL FIPS mode. I tried running the normal test suites after switching the OpenSSL installation to FIPS mode, but that failed all over the place. So I embarked on fixing that. Attached is a first iteration of a patch. The main issue is liberal use of the md5() function in tests to generate random strings. For example, this is a common pattern: SELECT x, md5(x::text) FROM generate_series(-10,10) x; This can be replaced by SELECT x, encode(sha256(x::text::bytea), 'hex') FROM generate_series(-10,10) x; In most cases, this could be further simplified by not using text but bytea for the column types, thus skipping the encode step. Some tests are carefully calibrated to achieve a certain column size or something like that. These will need to be checked in more detail. Another set of issues is in the SSL tests, where apparently some certificates are generated with obsolete hash methods, probably SHA1 (and possibly MD5 again). Some of this can be addressed by just regenerating everything with a newer OpenSSL installation, in some other cases it appears to need additional command-line options or a local configuration file change. This needs more research. I think we should augment the setup used to generate these test files in a way that they don't depend on the local configuration of whoever runs it. Of course, there are some some tests where we do want to test MD5 functionality, such as in the authentication tests or in the tests of the md5() function itself. I think we can conditionalize these somehow. That looks like a smaller issue compared to the issues above.
Вложения
В списке pgsql-hackers по дате отправления: