Re: [PATCH] Log details for client certificate failures
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Log details for client certificate failures |
Дата | |
Msg-id | 20220715203500.vanqxt23bmufjais@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Log details for client certificate failures (Jacob Champion <jchampion@timescale.com>) |
Ответы |
Re: [PATCH] Log details for client certificate failures
|
Список | 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
В списке pgsql-hackers по дате отправления: