On 08/05/2014 10:46 PM, Robert Haas wrote:
> On Mon, Aug 4, 2014 at 10:38 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> Now that we use TAP for testing client tools, I think we can use that to
>> test various SSL options too. I came up with the attached. Comments?
>>
>> It currently assumes that the client's and the server's hostnames are
>> "postgres-client.test" and "postgres-server.test", respectively. That makes
>> it a bit tricky to run on a single systme. The README includes instructions;
>> basically you need to set up an additional loopback device, and add entries
>> to /etc/hosts for that.
>
> That seems so onerous that I think few people will do it, and not
> regularly, resulting in the tests breaking and nobody noticing.
> Reconfiguring the loopback interface like that requires root
> privilege, and won't survive a reboot, and doing it in the system
> configuration will require hackery specific to the particular flavor
> of Linux you're running, and probably other hackery on non-Linux
> systems (never mind Windows).
Yeah, you're probably right.
> Why can't you make it work over 127.0.0.1?
I wanted it to be easy to run the client and the server on different
hosts. As soon as we have more than one SSL implementation, it would be
really nice to do interoperability testing between a client and a server
using different implementations.
Also, to test sslmode=verify-full, where the client checks that the
server certificate's hostname matches the hostname that it connected to,
you need to have two aliases for the same server, one that matches the
certificate and one that doesn't. But I think I found a way around that
part; if the certificate is set up for "localhost", and connect to
"127.0.0.1", you get a mismatch.
So, I got rid of the DNS setup, it only depends localhost/127.0.0.1 now.
Patch attached. That means that it's not easy to run the client and the
server on different hosts, but we can improve that later.
- Heikki