I'm withdrawing this patch, as the same feature was already implemented
in a different patch written by Jacob[1]
Thanks everyone!
Best, Jim
1-
https://www.postgresql.org/message-id/flat/caawbhmi4v9zeavfuscdfx1por3zwrv9fuxkv_2marqvyc-m...@mail.gmail.com#199c1f49fbefa6be401db35f5cfa7742
On Sun, Jan 29, 2023 at 5:02 AM Jim Jones wrote:
> On 27.01.23 21:13, Cary Huang wrote:
> > But, if the server does request clientcert but client uses
> "sslcertmode=disable" to connect and not give a certificate, it would
> also result in authentication failure. In this case, we actually would
On Fri, Jan 27, 2023 at 12:13 PM Cary Huang wrote:
> > (Eventually I'd like to teach the server not to ask for a client
> > certificate if it's not going to use it.)
>
> If clientcert is not requested by the server, but yet the client still
> sends the certificate, the server will still verify
On 27.01.23 21:13, Cary Huang wrote:
I agree that it is a more elegant approach to add
"sslcertmode=disable" on the client side to prevent sending default
certificate.
But, if the server does request clientcert but client uses
"sslcertmode=disable" to connect and not give a certificate, it
> I think the sslcertmode=disable option that I introduced in [1] solves
> this issue too; would it work for your case? That whole patchset is
> meant to tackle the general case of the problem you've described.
>
> (Eventually I'd like to teach the server not to ask for a client
> certificate if
Hello Jacob,
> 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
On Wed, Jan 25, 2023 at 7:47 AM Israel Barth Rubio
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
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
On Sat, Jan 21, 2023 at 4:35 AM Jim Jones wrote:
> 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
Hi Jacob,
> 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
On Fri, Jan 20, 2023 at 11:09 AM Jim Jones wrote:
> 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
Hello Israel,
Thanks a lot for the suggestion!
> 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,
Hello Jim,
> Hi Jelte, thanks for the message. You're right, an invalid cert path
> does solve the issue - I even use it for tests. Although it solves the
> authentication issue it still looks in my eyes like a non intuitive
> workaround/hack. Perhaps a new sslmode isn't the right place for this
Hi Jelte, thanks for the message. You're right, an invalid cert path
does solve the issue - I even use it for tests. Although it solves the
authentication issue it still looks in my eyes like a non intuitive
workaround/hack. Perhaps a new sslmode isn't the right place for this
"feature"?
The easiest way to achieve the same (without patching libpq) is by setting
sslcert to something non-existent. While maybe not the most obvious way, I
would consider this the recommended approach.
(sorry for the resend Jim, my original message got blocked to the wider
mailing list)
On Fri, 6 Jan
Dear PostgreSQL Hackers,
Some time ago we faced a small issue in libpq regarding connections
configured in the pg_hba.conf as type *hostssl* and using *md5* as
authentication method.
One of our users placed the client certificates in ~/.postgresql/
(*postgresql.crt,**postgresql.key*), so
16 matches
Mail list logo
