| From: | Jacob Champion <jchampion(at)timescale(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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:20:59 |
| Message-ID: | ca6eb74e-aafc-f7cc-50fd-a6b33bca858b@timescale.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. Is
this more dangerous than that? (And do we want to fix it now,
regardless?) What guarantees are we supposed to be making for log encoding?
Thanks,
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-07-15 20:35:00 | Re: [PATCH] Log details for client certificate failures |
| Previous Message | Andres Freund | 2022-07-15 20:08:57 | Re: optimize lookups in snapshot [sub]xip arrays |