From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Cary Huang <cary(dot)huang(at)highgo(dot)ca> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sslinfo extension - add notbefore and notafter timestamps |
Date: | 2023-09-12 19:40:04 |
Message-ID: | d20a3ac4-ff3c-d7c4-6344-22a7c6d2bba9@timescale.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
On 7/25/23 07:21, Daniel Gustafsson wrote:
> The attached version passes ssl tests for me on 1.0.2 through OpenSSL Git HEAD.
Tests pass for me too, including LibreSSL 3.8.
> + /* Calculate the diff from the epoch to the certificat timestamp */
"certificate"
> + <function>ssl_client_get_notbefore() returns text</function>
> ...> + <function>ssl_client_get_notafter() returns text</function>
I think this should say timestamptz rather than text? Ditto for the
pg_stat_ssl documentation.
Speaking of which: is the use of `timestamp` rather than `timestamptz`
in pg_proc.dat intentional? Will that cause problems with comparisons?
--
I haven't been able to poke any holes in the ASN1_TIME_to_timestamp()
implementations themselves. I went down a rabbit hole trying to find out
whether leap seconds could cause problems for us when we switch to
`struct tm` in the future, but it turns out OpenSSL rejects leap seconds
in the Validity fields. That seems weird -- as far as I can tell, RFC
5280 defers to ASN.1 which defers to ISO 8601 which appears to allow
leap seconds -- but I don't plan to worry about it anymore. (I do idly
wonder whether some CA, somewhere, has ever had a really Unhappy New
Year due to that.)
Thanks,
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-09-12 20:51:25 | Re: Avoid a possible null pointer (src/backend/utils/adt/pg_locale.c) |
Previous Message | Matthias van de Meent | 2023-09-12 15:51:30 | Re: GenBKI emits useless open;close for catalogs without rows |