From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jacob Champion <jchampion(at)timescale(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Log details for client certificate failures |
Date: | 2022-07-15 20:35:00 |
Message-ID: | 20220715203500.vanqxt23bmufjais@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-07-15 13:20:59 -0700, Jacob Champion wrote:
> On 7/15/22 12:11, Andres Freund wrote:
> > This might have been discussed somewhere, but I'm worried about emitting
> > unescaped data from pre-auth clients. What guarantees that subject / issuer
> > name only contain printable ascii-chars? Printing terminal control chars or
> > such would not be great, nor would splitting a string at a multi-boundary.
>
> Hm. The last time I asked about that, Magnus pointed out that we reflect
> port->user_name as-is [1], so I kind of stopped worrying about it.
I think we need to fix a number of these. But no, I don't think we should just
add more because we've not been careful in a bunch of other places.
> Is this more dangerous than that?
Hard to say.
> (And do we want to fix it now, regardless?)
Yes.
> What guarantees are we supposed to be making for log encoding?
I don't know, but I don't think not caring at all is a good
option. Particularly for unauthenticated data I'd say that escaping everything
but printable ascii chars is a sensible approach.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-07-15 20:36:59 | Re: PG15 beta1 sort performance regression due to Generation context change |
Previous Message | Jacob Champion | 2022-07-15 20:20:59 | Re: [PATCH] Log details for client certificate failures |