From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | Israel Barth Rubio <barthisrael(at)gmail(dot)com> |
Cc: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Jelte Fennema <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist |
Date: | 2023-01-25 17:09:47 |
Message-ID: | CAAWbhmiYE+fqaZ+LX55fxtWMYMSa8vz9YnD_=cDio-sunTyG2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 25, 2023 at 7:47 AM Israel Barth Rubio
<barthisrael(at)gmail(dot)com> wrote:
> 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'm not sure how helpful it is to assign "blame" here. I think the
requested improvement is reasonable -- it should be possible to
override the default for a particular connection, without having to
pick a junk value that you hope doesn't match up with an actual file
on the disk.
> 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.
sslmode=disable isn't used in either of our proposals, though. Unless
I'm missing what you mean?
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-01-25 17:21:14 | Re: CREATE ROLE bug? |
Previous Message | Pavel Stehule | 2023-01-25 17:02:07 | Re: Re: Support plpgsql multi-range in conditional control |