> > The recent bump in minmum required versions of OpenSSL and LibreSSL made me
> > remember to revisit this patch which was previously reverted due to library
> > incompatibility (with *both* OpenSSL and LibreSSL on different APIs).
> >
> > The attached removes the timestamp conversion worka
On Mon, Oct 28, 2024 at 09:59:35AM +0100, Daniel Gustafsson wrote:
> The recent bump in minmum required versions of OpenSSL and LibreSSL made me
> remember to revisit this patch which was previously reverted due to library
> incompatibility (with *both* OpenSSL and LibreSSL on different APIs).
>
>
The recent bump in minmum required versions of OpenSSL and LibreSSL made me
remember to revisit this patch which was previously reverted due to library
incompatibility (with *both* OpenSSL and LibreSSL on different APIs).
The attached removes the timestamp conversion workaround which is no longer
On Fri, Mar 22, 2024 at 6:15 AM Daniel Gustafsson wrote:
> While staging this to commit I realized one silly thing about it warranting
> another round here. The ASN.1 timediff code can diff against *any* timestamp,
> not just the UNIX epoch, so we could just pass in the postgres epoch and skip
>
> On 20 Mar 2024, at 17:32, Jacob Champion
> wrote:
> I can't find anything else to note; patch LGTM.
While staging this to commit I realized one silly thing about it warranting
another round here. The ASN.1 timediff code can diff against *any* timestamp,
not just the UNIX epoch, so we could j
On Wed, Mar 20, 2024 at 7:50 AM Daniel Gustafsson wrote:
> We are subtracting 30 years from a calculation that we know didnt overflow, so
> I guess if the certificate notBefore (the notAfter cannot be that early since
> we wouldn't be able to connect with it) was set to early enough? It didn't
>
> On 20 Mar 2024, at 15:28, Jacob Champion
> wrote:
>> + result -= ((POSTGRES_EPOCH_JDATE - UNIX_EPOCH_JDATE) * USECS_PER_DAY);
>> + return TimestampTzGetDatum(result);
>
> Is that final bare subtraction able to wrap around for dates far in the past?
We are subtracting 30 years from a calc
On Wed, Mar 20, 2024 at 7:03 AM Daniel Gustafsson wrote:
> The issue here is that postgres use a different epoch from the unix epoch, so
> any dates calcuated based on the unix epoch need to be adjusted.
Ah, thank you! I had just reproduced Cary's problem and was really confused...
> I've hacked
> On 20 Mar 2024, at 00:24, Cary Huang wrote:
> but it seems to me that many of the timestamp related functions still consider
> timestamp or timestampTz as "double values with units of seconds" though.
The issue here is that postgres use a different epoch from the unix epoch, so
any dates calc
Thank you for your review again.
> ...but I think Timestamp[Tz]s are stored as microseconds, so we're off
> by a factor of a million. This still works because later we cast to
> double and pass it back through float8_timestamptz, which converts it:
In my test, if I made ASN1_TIME_to_timestamp
On Mon, Mar 18, 2024 at 1:48 PM Cary Huang wrote:
> Attached is the v10 patch with the above changes. Thanks again for the review.
Awesome, looks good.
On my final review pass I saw one last thing that bothered me (sorry
for not seeing it before). The backend version of
ASN1_TIME_to_timestamptz
Hi Jacob
> Hi Cary, did you have any thoughts on the timestamptz notes from my last mail?
>
> > It might also be nice to rename
> > ASN1_TIME_to_timestamp().
> >
> > Squinting further at the server backend implementation, should that
> > also be using TimestampTz throughout, instead of Timestamp?
On Fri, Mar 8, 2024 at 4:16 PM Cary Huang wrote:
> Yes, I noticed this in the SSL test too. I am also in GTM-8, so for me the
> tests would fail too due to the time zone differences from GMT. It shall be
> okay to specifically set the outputs of pg_stat_ssl,
> ssl_client_get_notbefore, and ssl_
Hello
Thank you for the review and your patch. I have tested with minimum OpenSSL
version 1.0.2 support and incorporated your changes into the v9 patch as
attached.
> In my -08 timezone, the date doesn't match what's recorded either
> (it's my "tomorrow"). I think those probably just need to
On Mon, Mar 4, 2024 at 6:23 AM Daniel Gustafsson wrote:
> > On 12 Sep 2023, at 21:40, Jacob Champion wrote:
Sorry for the long delay!
> >> + ssl_client_get_notbefore() returns text
> >> ...> + ssl_client_get_notafter() returns text
> >
> > I think this should say timestamptz rather than
> On 12 Sep 2023, at 21:40, Jacob Champion wrote:
>
> 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.
Thanks for testing!
>> + /* Calculate the dif
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"
> + ssl_client_get_n
> On 20 Jul 2023, at 17:24, Daniel Gustafsson wrote:
>
>> On 17 Jul 2023, at 20:26, Cary Huang wrote:
>
Perhaps calling "tm2timestamp(&pgtm_time, 0, NULL, &ts)" without checking
the return code would be just fine. I see some other usages of
tm2timstamp() in other code areas als
> On 17 Jul 2023, at 20:26, Cary Huang wrote:
>>> Perhaps calling "tm2timestamp(&pgtm_time, 0, NULL, &ts)" without checking
>>> the return code would be just fine. I see some other usages of
>>> tm2timstamp() in other code areas also skip checking the return code.
>>
>> I think we want to know
Hello
> > Perhaps calling "tm2timestamp(&pgtm_time, 0, NULL, &ts)" without checking
> > the return code would be just fine. I see some other usages of
> > tm2timstamp() in other code areas also skip checking the return code.
>
> I think we want to know about any failures, btu we can probab
> On 14 Jul 2023, at 20:41, Cary Huang wrote:
> Perhaps calling "tm2timestamp(&pgtm_time, 0, NULL, &ts)" without checking the
> return code would be just fine. I see some other usages of tm2timstamp() in
> other code areas also skip checking the return code.
I think we want to know about any f
Hello
> The way we typically ship extensions in contrib/ is to not create a new base
> version .sql file for smaller changes like adding a few functions. For this
> patch we should keep --1.2.sql and instead supply a 1.2--1.3.sql with the new
> functions.
Thank you for pointing this out. It
I had another look at this today and I think this patch is in pretty good
shape, below are a few comments on this revision:
- 'sslinfo--1.2.sql',
+ 'sslinfo--1.2--1.3.sql',
+ 'sslinfo--1.3.sql',
The way we typically ship extensions in contrib/ is to not create a new base
version .sql file for
> Thanks for the new version! It doesn't fail the ssl tests, but the Kerberos
> test now fails. You can see the test reports from the CFBot here:
Yes, kerberos tests failed due to the addition of notbefore and notafter
values. The values array within "pg_stat_get_activity" function related to
> On 30 Jun 2023, at 20:12, Cary Huang wrote:
>
>> This needs to adjust the tests in src/test/ssl which now fails due to SELECT
>> *
>> returning a row which doesn't match what the test was coded for.
>
> Thank you so much for pointing out. I have adjusted the extra ssl test to
> account for t
> This needs to adjust the tests in src/test/ssl which now fails due to SELECT
> *
> returning a row which doesn't match what the test was coded for.
Thank you so much for pointing out. I have adjusted the extra ssl test to
account for the extra columns returned. It should not fail now.
>
> On 23 Jun 2023, at 22:10, Cary Huang wrote:
>> Off the cuff that doesn't seem like a bad idea, but I wonder if we should add
>> them to pg_stat_ssl (or both) instead if we deem them valuable?
>
> I think the same information should be available to pg_stat_ssl as well.
> pg_stat_ssl can show
> Yes, please add it to the July commitfest and feel free to set me as
> Reviewer,
> I intend to take a look at it.
Thank you Daniel, I have added this patch to July commitfest under security
category and added you as reviewer.
best regards
Cary Huang
-
HighGo Software Inc. (Ca
> On 23 Jun 2023, at 22:10, Cary Huang wrote:
> would this feature be suitable to be added to commitfest? What do you think?
Yes, please add it to the July commitfest and feel free to set me as Reviewer,
I intend to take a look at it.
--
Daniel Gustafsson
> Off the cuff that doesn't seem like a bad idea, but I wonder if we should add
> them to pg_stat_ssl (or both) instead if we deem them valuable?
I think the same information should be available to pg_stat_ssl as well.
pg_stat_ssl can show the client certificate information for all connecting
> On 20 Aug 2022, at 01:00, Cary Huang wrote:
> I noticed that sslinfo extension does not have functions to return current
> client certificate's notbefore and notafter timestamps which are also quite
> important attributes in a X509 certificate. The attached patch adds 2
> functions to get no
Hello
I noticed that sslinfo extension does not have functions to return current
client certificate's notbefore and notafter timestamps which are also quite
important attributes in a X509 certificate. The attached patch adds 2 functions
to get notbefore and notafter timestamps from the curren
32 matches
Mail list logo
