Cleanup old 'time' dependency and make local time available

[Byron]

The motivation for this is to provide a way to obtain the local time in seconds since epoch along with a timezone offset for use in git-actor::Signature, providing something similar to git2::Signature::now().

What is just a few innocent looking lines of code in C ) actually is a can full of worms, best summarized with with this comment:

quininer says

setenv and getenv are not thread-safe, and localtime_r will call getenv, which cause to data races if setenv and localtime_r occur at same time.

To be more specific, getenv will return a pointer, and after setenv the pointer may point to an invalid address.

In order to fix this for gitoxide, the following should be done

• prodash relies on an outdated version of time with unsound behaviour to make its local-time feature work.
  • In time 0.3 handling this is greatly improved as it exposes the unsound behaviour exploited here in a compiler flag, placing support for this into the hands of the one compiling the binary. This is fair and we should do it like that
• The above allows to remove an exemption from deny.toml and upgrade to prodash 16
• configure binary builds to add the unsound_local_offset config flag
• Add a libc implementation based on [libgit2](libgit2-offset] (not portable) Wrap the time implementation for now, knowing that one day it can be done properly
  • It's interesting that it also excludes windows, which might work very differently and was never discussed in the the time issue - it doesn't actually, it's a unix-only issue.

[Byron]

@kim Implementing git2::Signature::now(…) opens up old tech-debt that laid dormant and was almost forgotten, and shows that getting the local time can't possibly be done safely right now without a pure-rust implementation or workarounds that just make segfaults less likely by caching the TZ offset and hoping for the best the one time it is queried.

What's your thoughts on this course of action? Is a pure Rust implementation feasible to avoid such a workaround? I am very curious to get your ideas on the matter.

Edit: The workaround really is needed only unix, so doing what libc does to get the timezone offset seems to be 'all' that's needed to solve the problem once and for all. For now it seems OK to live with the cfg(unsound_local_offset) workaround, a client-only feature anyway.

[Byron]

I mean, with knowledge about the MUSL implementation and a zone file parser it should be very possible to implement whatever libc does, but without the race around the TZ environment variable. time would be happy to have a PR for removing the current workaround.

[kim]

Oh my, a can of worms indeed.

I'm thinking that it is probably best to avoid local time in long running processes. We've been using git2::Signature::now for convenience, but there is no reason we couldn't use UTC -- it's not that we're making commits on behalf of the user, but more as a "bot user". So, a now_utc convenience function would be more than sufficient for us.

It is however the case that git2::Signature::now also resolves user.name and user.email from the config, so I'm wondering how git-actor wants to deal with this?

[Byron]

I'm thinking that it is probably best to avoid local time in long running processes.

I couldn't agree more, it's definitely a client-side feature.

We've been using git2::Signature::now for convenience, but there is no reason we couldn't use UTC -- it's not that we're making commits on behalf of the user, but more as a "bot user". So, a now_utc convenience function would be more than sufficient for us.

I will make it Signature::now_utc() instead for the test code to accelerate this.

It is however the case that git2::Signature::now also resolves user.name and user.email from the config, so I'm wondering how git-actor wants to deal with this?

In the test it's configured, but on git-repository level there may be a version of this that constructs the signature solely from git-config and environment variables. Plumbing crates are the lucky ones, they don't have to deal with the thousand ways git can be configured 😅.