Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist

Hello Jim/Jacob,

> > I do not think it is worth it to change the current behavior of
> PostgreSQL
> > in that sense.

> 
> Well, I am not suggesting to change the current behavior of PostgreSQL in
> that matter. Quite the contrary, I find this feature very convenient,
> specially when you need to deal with many different clusters. What I am
> proposing is rather the possibility to disable it on demand :) I mean,
> in case I do not want libpq to try to authenticate using the certificates
> in `~/.postgresql`.
> 
> > PostgreSQL looks for the cert and key under `~/.postgresql` as a
> facility.
> > These files do not exist by default, so if PostgreSQL finds something in
> > there it assumes you want to use it.
> 
> Yes. I'm just trying to find an elegant way to disable this assumption
> on demand.

Right, I do understand your proposal. I was just thinking out loud and

wondering about the broad audience of such a mode in the sslmode

argument.

Something else that came to my mind is that sslmode itself seems more

like an argument covering the client expectations regarding the connection

to the server, I mean, if it expects channel encryption and/or validation of the

server identity.

I wonder if we are willing to add some functionality around the expectations

regarding the client certificate, if it wouldn't make more sense to be controlled

through something like the clientcert option of pg_hba? If so, the downside of

that is the fact that the client would still send the certificate even if it would not

be used at all by the server. Again, just thinking out loud about what your goal

is and possible ways of accomplishing that:)

> > I do realize that this patch is a big ask, since probably nobody except
> > me "needs it" :D
> 
> I'd imagine other people have run into it too; it's just a matter of
> how palatable the workarounds were to them. :)

I imagine more people might have already hit a similar situation too. While the

workaround can seem a bit weird, in my very humble opinion the user/client is

somehow still the one to blame in this case as it is providing the "wrong" file in

a path that is checked by libpq. With that in mind I would be inclined to say it is

an acceptable workaround.

> > I think the sslcertmode=disable option that I introduced in [1]
solves this issue too;
> 
> Well, I see there is indeed a significant overlap between our patches -
> but yours has a much more comprehensive approach! If I got it right,
> the new slcertmode=disable would indeed cancel the existing certs in
> '~/.postgresql/ in case they exist. Right?
> 
> +    if (conn->sslcertmode[0] == 'd') /* disable */
> +    {
> +        /* don't send a client cert even if we have one */
> +        have_cert = false;
> +    }
> +    else if (fnbuf[0] == '\0')
> 
> My idea was rather to use the existing sslmode with a new option
> "no-clientcert" that does actually the same:
> 
>      /* sslmode no-clientcert */
>      if (conn->sslmode[0] == 'n')
>      {
>          fnbuf[0] = '\0';
>      }
> 
>      ...
> 
>      if (fnbuf[0] == '\0')
>      {
>          /* no home directory, proceed without a client cert */
>          have_cert = false;
>      }
> 
> I wish I had found your patchset some months ago. Now I hate myself
> for the duplication of efforts :D

Although both patches achieve a similar goal regarding not sending the

client certificate there is still a slight but in my opinion important difference

between them: sslmode=disable will also disable channel encryption. It

may or may not be acceptable depending on how the connection is between

your client and the server.

Kind regards,
Israel.