From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Jacob Champion <pchampion(at)vmware(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-05-04 13:53:27 |
Message-ID: | 290871e5-f1d9-54a8-5df4-dbd9e604c08d@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04.05.22 01:05, Jacob Champion wrote:
> On Tue, 2022-05-03 at 21:06 +0200, Peter Eisentraut wrote:
>> The information in pg_stat_ssl is limited to NAMEDATALEN (see struct
>> PgBackendSSLStatus).
>>
>> It might make sense to align what your patch prints to identify
>> certificates with what is shown in that view.
>
> Sure, a max length should be easy enough to do. Is there a reason to
> limit to NAMEDATALEN specifically? I was under the impression that we
> would rather not have had that limitation in the stats framework, if we
> could have avoided it. (In particular I think NAMEDATALEN will cut off
> the longest possible Common Name by just five bytes.)
Just saying that cutting it off appears to be acceptable. A bit more
than 63 bytes should be okay for the log.
In terms of aligning what is printed, I meant that pg_stat_ssl uses the
issuer plus serial number to identify the certificate unambiguously.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-05-04 13:56:13 | Re: bogus: logical replication rows/cols combinations |
Previous Message | Tom Lane | 2022-05-04 13:40:03 | Re: Add pg_strtoupper and pg_strtolower functions |