On 12.09.21 16:21, Ævar Arnfjörð Bjarmason wrote:
>
> On Sun, Sep 12 2021, Fabian Stelzer wrote:
>
>> Hi,
>> while working on correct key rollover and verifying signatures for past
>> commits for the ssh signing topic i am trying to understand how Git
>> deals with timestamps for commits & tags.
>> For ssh signing the user will manage expiration times within their
>> allowedSigners file. Those timestamps do not carry a timezone and i
>> would assume a user (or automatic generation of this file) will assume
>> the systems timezone for them.
>> Therefore i wanted to pass the commit & tags timestamps adjusted to the
>> system timezone to make sure key rollover will have no gaps or failed
>> verification's especially when commit and system timezone differ greatly
>> and might roll over to another day.
>>
>> However the commit & tags structs only seem to carry the objects
>> timestamp as is, simply ignoring any timezone information. For the ssh
>> feature i can easily enough parse the ident line again from the object
>> header. But while looking at the usage of the existing date fields i can
>> see that objects are sometimes sorted on and compared by these dates.
>> When commands provide cut off times (--since) i think they might include
>> or exclude commits erroneously when they were made in a different
>> timezone around the cutoff date. ("log --since" indeed gives me some
>> unexpected results when mixing multiple timezones. Based on some simple
>> testing i think it just stops output when a commit falls outside of this
>> window, even though there might be one before it wich is within)
>>
>> Is my understanding of this correct and this the expected behaviour?
>> I think generally for git this does not matter much. But in certain
>> situations this is problematic.
>>
>> I would have assumed that git would either add the timezone as well or
>> adjust the commit timestamp upon populating the date field in the commit
>> struct to UTC but i could not find anything like it.
>
> Timezones are ultimately display information that's confusing to humans,
> but not machines. Machines just need to deal with epochs, or when a
> human supplies them a date convert a formatted date + timezone pair to
> an epoch.
>
> So in the key expiry case, I'd expect that any such system would say
> issue keys right now, now as in time(NULL), and we'd set those keys to
> expire after some time, say 1 day, so time(NULL) + 60 * 60 * 24;
>
> If you're in UTC that might yield a very satisfying (to humans, a
> machine won't care) expiry time. I.e. you'll get keys issued say at
> midnight, and expiring midnight the following day.
>
> What you're saying sounds to me like you're conflating the two
> things.
You are correct. I somehow thought the stored timestamp would be in the
specified timezone when it is not. The timezone is only used as
reference for display.
> Anyway, maybe I've misunderstood you. I just don't see how something
> like key expiry would need to concern itself with anything but
> epochs. If you conflate timezones with that and say "here's a key, it
> expires at mindight" surely you'll have some keys last mere seconds,
> others 10 hours etc.
>
The ssh allowedSigners file specifies key expiry in a "%Y%m%d%H%M%S"
format without any timezone information. So i have to assume the systems
timezone is used.
But correcting my misconception of the stored commit timestamp i can
simply present it in the systems timezone for ssh to compare it with the
specified expiry date.
Thanks for your help!
