Re: ssh-keygen -V doesn't respect DST

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxxxx> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux