Update Rust crate chrono to 0.4.30 #172
Reference in New Issue
Block a user
Delete Branch "renovate/chrono-0.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
0.4.29->0.4.30Release Notes
chronotope/chrono (chrono)
v0.4.30: 0.4.30Compare Source
In this release, we have decided to swap out the
chrono::Durationtype (which has been a re-export of time 0.1Durationtype) with our own definition, which exposes a strict superset of thetime::DurationAPI. This helps avoid warnings about the CVE-2020-26235 and RUSTSEC-2020-0071 advisories for downstream users and allows us to improve theDurationAPI going forward.While this is technically a SemVer-breaking change, we expect the risk of downstream users experiencing actual incompatibility to be exceedingly limited (see our analysis of public code using a crater-like experiment), and not enough justification for the large ecosystem churn of a 0.5 release. If you have any feedback on these changes, please let us know in #1268.
Additions
NaiveDate::leap_year(#1261)Documentation
Timelike::num_seconds_from_midnightis a simple mapping (#1255)Relation between chrono and time 0.1
Rust first had a
timemodule added tostdin its 0.7 release. It later moved tolibextra, and then to alibtimelibrary shipped alongside the standard library. In 2014 work on chrono started in order to provide a full-featured date and time library in Rust. Some improvements from chrono made it into the standard library; notably,chrono::Durationwas included asstd::time::Duration(rust#15934) in 2014.In preparation of Rust 1.0 at the end of 2014
libtimewas moved out of the Rust distro and into thetimecrate to eventually be redesigned (rust#18832, rust#18858), like thenumandrandcrates. Of course chrono kept its dependency on thistimecrate.timestarted re-exportingstd::time::Durationduring this period. Later, the standard library was changed to have a more limited unsignedDurationtype (rust#24920, RFC 1040), while thetimecrate kept the full functionality withtime::Duration.time::Durationhad been a part of chrono's public API.By 2016
time0.1 lived under therust-lang-deprecatedorganisation and was not actively maintained (time#136). chrono absorbed the platform functionality andDurationtype of thetimecrate in chrono#478 (the work started in chrono#286). In order to preserve compatibility with downstream crates depending ontimeandchronosharing aDurationtype, chrono kept depending on time 0.1. chrono offered the option to opt out of thetimedependency by disabling theoldtimefeature (swapping it out for an effectively similar chrono type). In 2019, @jhpratt took over maintenance on thetimecrate and released what amounts to a new crate astime0.2.Security advisories
In November of 2020 CVE-2020-26235 and RUSTSEC-2020-0071 were opened against the
timecrate. @quininer had found that calls tolocaltime_rmay be unsound (chrono#499). Eventually, almost a year later, this was also made into a security advisory against chrono as RUSTSEC-2020-0159, which had platform code similar totime.On Unix-like systems a process is given a timezone id or description via the
TZenvironment variable. We need this timezone data to calculate the current local time from a value that is in UTC, such as the time from the system clock.time0.1 and chrono used the POSIX functionlocaltime_rto do the conversion to local time, which reads theTZvariable.Rust assumes the environment to be writable and uses locks to access it from multiple threads. Some other programming languages and libraries use similar locking strategies, but these are typically not shared across languages. More importantly, POSIX declares modifying the environment in a multi-threaded process as unsafe, and
getenvin libc can't be changed to take a lock because it returns a pointer to the data (see rust#27970 for more discussion).Since version 4.20 chrono no longer uses
localtime_r, instead using Rust code to query the timezone (from theTZvariable or viaiana-time-zoneas a fallback) and work with data from the system timezone database directly. The code for this was forked from the tz-rs crate by @x-hgg-x. As such, chrono now respects the Rust lock when reading theTZenvironment variable. In general, code should avoid modifying the environment.Removing time 0.1
Because time 0.1 has been unmaintained for years, however, the security advisory mentioned above has not been addressed. While chrono maintainers were careful not to break backwards compatibility with the
time::Durationtype, there has been a long stream of issues from users inquiring about the time 0.1 dependency with the vulnerability. We investigated the potential breakage of removing the time 0.1 dependency in chrono#1095 using a crater-like experiment and determined that the potential for breaking (public) dependencies is very low. We reached out to those few crates that did still depend on compatibility with time 0.1.As such, for chrono 0.4.30 we have decided to swap out the time 0.1
Durationimplementation for a local one that will offer a strict superset of the existing API going forward. This will prevent most downstream users from being affected by the security vulnerability in time 0.1 while minimizing the ecosystem impact of semver-incompatible version churn.Thanks to all contributors on behalf of the chrono team, @djc and @pitdicker!
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.