Mailing List Archive

ssh-keygen -V doesn't respect DST
Hi,
we just entered DST here in Czech Republic, and my CA started generating certificates with a +1h offset:

ssh-keygen -U -s some-ca-key.pub -V 20220328110400:20220328112400 -I 981-20220328-1104 -O extension:login@github.com=someone@github.com -I eed3f7c7-4809-46e7-892e-6e3642da59c8 438.pub

Signed user key 438-cert.pub: id "eed3f7c7-4809-46e7-892e-6e3642da59c8 " serial 0 valid from 2022-03-28T12:04:00 to 2022-03-28T12:24:00


$ date
Mon Mar 28 11:21:25 CEST 2022
$ ls -la /etc/localtime
lrwxrwxrwx. 1 root root 35 Jun 8 2020 /etc/localtime -> ../usr/share/zoneinfo/Europe/Prague

As a workaround, I set /usr/share/zoneinfo/Etc/GMT-1 as a timezone, but this is clearly not right.

Any plans to fix this? Apparently I am not the only person who encountered it https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py#L72 <https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py#L72>

Thanks
Jan

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh-keygen -V doesn't respect DST [ In reply to ]
On Mon, Mar 28, 2022 at 11:23:35AM +0200, Jan Schermer wrote:
> Hi,
> we just entered DST here in Czech Republic, and my CA started generating certificates with a +1h offset:
[...]
> Any plans to fix this? Apparently I am not the only person who encountered it https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py#L72 <https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py#L72>

Assuming I'm read the man page right, I think this should fix it.

diff --git a/misc.c b/misc.c
index 85d223695..03e6e5f19 100644
--- a/misc.c
+++ b/misc.c
@@ -2429,6 +2429,7 @@ parse_absolute_time(const char *s, uint64_t *tp)
memset(&tm, 0, sizeof(tm));
if (strptime(buf, fmt, &tm) == NULL)
return SSH_ERR_INVALID_FORMAT;
+ tm.tm_isdst = -1; /* auto detect DST */
if ((tt = mktime(&tm)) < 0)
return SSH_ERR_INVALID_FORMAT;
/* success */

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh-keygen -V doesn't respect DST [ In reply to ]
On 3/28/22 11:23, Jan Schermer wrote:
> we just entered DST here in Czech Republic, and my CA started
> generating certificates with a +1h offset: >
> ssh-keygen -U -s some-ca-key.pub -V 20220328110400:20220328112400 [..]
>
> Signed user key 438-cert.pub: id
> "eed3f7c7-4809-46e7-892e-6e3642da59c8 " serial 0 valid from
> 2022-03-28T12:04:00 to 2022-03-28T12:24:00
Reading ssh-keygen(1) I have no clue whether time strings specified with
-V are supposed to be local time or UTC.

IMHO implying local time could cause all sorts of strange issues in case
time-zone info is not correctly set for a service etc.

> Any plans to fix this? Apparently I am not the only person who
> encountered it
> https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py#L72

My own implementation only uses relative time format like "+4h". AFAICS
the spec in PROTOCOL.certkeys defines the validity period based on
time-stamps with senconds-since-epoch (UTC).

Ciao, Michael.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh-keygen -V doesn't respect DST [ In reply to ]
On 3/28/22 15:48, Michael Ströder wrote:
> On 3/28/22 11:23, Jan Schermer wrote:
>> we just entered DST here in Czech Republic, and my CA started
>> generating certificates with a +1h offset:
>>
>> ssh-keygen -U -s some-ca-key.pub -V 20220328110400:20220328112400 [..]
>
> Reading ssh-keygen(1) I have no clue whether time strings specified with
> -V are supposed to be local time or UTC.
> [..]
>> Any plans to fix this? Apparently I am not the only person who
>> encountered it
>> https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py#L72

Looking closer at the above Python code it seems to implement some
strange DST assumptions. IMHO the author of cloudtools/ssh-ca should fix
this (e.g. by using a decent Python module for time-zone handling).

Ciao, Michael.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh-keygen -V doesn't respect DST [ In reply to ]
If I read the specs correctly then the certificate itself uses seconds since 1970-01-01 in its structures, but ssh-keygen always interprets input as local time and while doing this conversion doesn't take DST into account.

If the previously sent patch fixed it that simply (thanks for that) then that would at least make it work as designed. (Not sure about the case where the validity crosses the DST switch)

However, as you stated, I also concur that using local time is problematic in many ways and should be extended to support timezone in the date/time specification or at least feeding it epochtime directly - that at least should be a pretty straightforward way for application to calculate it properly.
That said, I expect the support to calculate that to be already present in mature form in libc(?) so why require application or user to think about it if they don't want to.

Jan

> On 28. 3. 2022, at 15:49, Michael Ströder <michael@stroeder.com> wrote:
>
> ?On 3/28/22 11:23, Jan Schermer wrote:
>> we just entered DST here in Czech Republic, and my CA started
>> generating certificates with a +1h offset: >
>> ssh-keygen -U -s some-ca-key.pub -V 20220328110400:20220328112400 [..]
>> Signed user key 438-cert.pub: id
>> "eed3f7c7-4809-46e7-892e-6e3642da59c8 " serial 0 valid from
>> 2022-03-28T12:04:00 to 2022-03-28T12:24:00
> Reading ssh-keygen(1) I have no clue whether time strings specified with -V are supposed to be local time or UTC.
>
> IMHO implying local time could cause all sorts of strange issues in case time-zone info is not correctly set for a service etc.
>
>> Any plans to fix this? Apparently I am not the only person who
>> encountered it
>> https://www.google.com/url?q=https://github.com/cloudtools/ssh-ca/blob/master/ssh_ca/utils.py%23L72&source=gmail-imap&ust=1649080190000000&usg=AOvVaw1IJidw6Hp6meZYNCN2Zl2X
>
> My own implementation only uses relative time format like "+4h". AFAICS the spec in PROTOCOL.certkeys defines the validity period based on time-stamps with senconds-since-epoch (UTC).
>
> Ciao, Michael.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://www.google.com/url?q=https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev&source=gmail-imap&ust=1649080190000000&usg=AOvVaw0uDCnWuDUlhIgQXyKn6JnW
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh-keygen -V doesn't respect DST [ In reply to ]
On Mon, 28 Mar 2022, Darren Tucker wrote:

> + tm.tm_isdst = -1; /* auto detect DST */

Despite this being precisely what POSIX’ strptime docs say…

https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html#tag_16_582_06

… tm_isdst is optional, and therefore this needs #ifdef HAVE_TM_ISDST
and a configure test. (Also, ouch, I didn’t know about this either;
very unintuitive API combination.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev