Message-ID: <d20a3ac4-ff3c-d7c4-6344-22a7c6d2bba9@timescale.com>
Date: Tue, 12 Sep 2023 12:40:04 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.0
Subject: Re: sslinfo extension - add notbefore and notafter timestamps
To: Daniel Gustafsson <daniel@yesql.se>, Cary Huang <cary.huang@highgo.ca>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <182b8565486.10af1a86f158715.2387262617218380588@highgo.ca>
 <42389B9C-D0AF-43B0-9554-EE38CE4505B2@yesql.se>
 <188e9e114e2.1168b3bda837794.3324050820866856527@highgo.ca>
 <10E8A199-26FF-4486-B00F-D3725577FBE4@yesql.se>
 <1890d814830.fd0e0b3d74296.8256991149346794664@highgo.ca>
 <513DF026-E3D9-48AC-86E0-CC30071D8EC2@yesql.se>
 <1894211830e.ef46f9012448790.7113590129448608981@highgo.ca>
 <EE288A58-947E-479A-9D99-C46C273D7A23@yesql.se>
 <18955b4d491.b58817e1615339.2313743524378473795@highgo.ca>
 <3B06C5ED-ED82-4583-9A70-BFCEC32E8689@yesql.se>
 <189651ac531.121770805396824.7203598683046078451@highgo.ca>
 <E664E9E7-EA33-4DB7-A166-F15E97FF35C4@yesql.se>
 <F14BF1AC-A765-402E-B49F-A303A8B38C75@yesql.se>
Content-Language: en-US
From: Jacob Champion <jchampion@timescale.com>
In-Reply-To: <F14BF1AC-A765-402E-B49F-A303A8B38C75@yesql.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/d20a3ac4-ff3c-d7c4-6344-22a7c6d2bba9%40timescale.com>
Precedence: bulk

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