On Wed, Mar 16, 2022 at 11:45:39AM +0100, Daniel Gustafsson wrote:
> On 16 Mar 2022, at 08:36, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
>> The attached fixes that and make-world successfully finished even if I
>> have a cert file in my home direcotory.
>
> Seems correct to me, thanks!
The ultimate test I can think about to stress the robustness of this
test suite is to generate various certs and keys using "make
sslfiles", save them into a ~/.postgresql/ (postgresql.crt,
postgresql.key, root.crl and root.crt), and then run the tests to see
how much junk data the SSL scripts would feed on. With this method, I
have caught a total of 71 failures, much more than reported upthread.
We should really put more attention to set invalid default values for
sslcert, sslkey, sslcrl, sslcrldir and sslrootcert, rather than
hardcoding a couple of them in only a few places, opening ourselves to
the same problem, again, each time a new test is added. The best way
I can think about here is to use a string that includes all the
default SSL settings, appending that at the beginning of each
$common_connstr. This takes care of most the failures, except two
cases related to expected failures for sslcrldir:
- directory CRL belonging to a different CA
- does not connect with client-side CRL directory
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.
Thoughts?
--
Michael
