On Thu, Mar 17, 2022 at 02:59:26PM +0900, Michael Paquier wrote:
> In both cases, enforcing sslcrl to a value of "invalid" interferes
> with the failure scenario we expect from sslcrldir. It is possible to
> bypass that with something like the attached, but that's a kind of
> ugly hack. Another alternative would be to drop those two tests, and
> I am not sure how much we care about these two negative scenarios.
Actually, there is a trick I have recalled here: we can enforce sslcrl
to an empty value in the connection string after the default. This
still ensures that the test won't pick up any SSL data from the local
environment and avoids any interferences of OpenSSL's
X509_STORE_load_locations(). This gives a much simpler and cleaner
patch.
Thoughts?
--
Michael