Valheim Docker powered by Odin. The Valheim dedicated gameserver manager which is designed with resiliency in mind by providing automatic updates, world backup support, and a user friendly cli interface.
chronotope/chrono (chrono)
### [`v0.4.30`](https://togithub.com/chronotope/chrono/releases/tag/v0.4.30): 0.4.30
[Compare Source](https://togithub.com/chronotope/chrono/compare/v0.4.29...v0.4.30)
In this release, we have decided to swap out the `chrono::Duration` type (which has been a re-export of time 0.1 `Duration` type) with our own definition, which exposes a strict superset of the `time::Duration` API. This helps avoid warnings about the [CVE-2020-26235] and [RUSTSEC-2020-0071] advisories for downstream users and allows us to improve the `Duration` API 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](https://togithub.com/chronotope/chrono/pull/1095#issuecomment-1571716955) 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](https://togithub.com/chronotope/chrono/issues/1268).
##### Additions
- Add `NaiveDate::leap_year` ([#1261](https://togithub.com/chronotope/chrono/issues/1261))
##### Documentation
- Update main documentation from README ([#1260](https://togithub.com/chronotope/chrono/issues/1260), thanks [@Stygmates](https://togithub.com/Stygmates))
- Add history of relation between chrono and time 0.1 to documentation ([https://github.com/chronotope/chrono/pull/1264](https://togithub.com/chronotope/chrono/pull/1264), [https://github.com/chronotope/chrono/pull/1266](https://togithub.com/chronotope/chrono/pull/1266))
- Clarify `Timelike::num_seconds_from_midnight` is a simple mapping ([#1255](https://togithub.com/chronotope/chrono/issues/1255))
#### Relation between chrono and time 0.1
Rust first had a `time` module added to `std` in its 0.7 release. It later moved to `libextra`, and then to a `libtime` library 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::Duration` was included as `std::time::Duration` ([rust#15934]) in 2014.
In preparation of Rust 1.0 at the end of 2014 `libtime` was moved out of the Rust distro and into the `time` crate to eventually be redesigned ([rust#18832], [rust#18858]), like the `num` and `rand` crates. Of course chrono kept its dependency on this `time` crate. `time` started re-exporting `std::time::Duration` during this period. Later, the standard library was changed to have a more limited unsigned `Duration` type ([rust#24920], [RFC 1040]), while the `time` crate kept the full functionality with `time::Duration`. `time::Duration` had been a part of chrono's public API.
By 2016 `time` 0.1 lived under the `rust-lang-deprecated` organisation and was not actively maintained ([time#136]). chrono absorbed the platform functionality and `Duration` type of the `time` crate in [chrono#478] (the work started in [chrono#286]). In order to preserve compatibility with downstream crates depending on `time` and `chrono` sharing a `Duration` type, chrono kept depending on time 0.1. chrono offered the option to opt out of the `time` dependency by disabling the `oldtime` feature (swapping it out for an effectively similar chrono type). In 2019, [@jhpratt](https://togithub.com/jhpratt) took over maintenance on the `time` crate and released what amounts to a new crate as `time` 0.2.
[rust#15934]: https://togithub.com/rust-lang/rust/pull/15934
[rust#18832]: https://togithub.com/rust-lang/rust/pull/18832#issuecomment-62448221
[rust#18858]: https://togithub.com/rust-lang/rust/pull/18858
[rust#24920]: https://togithub.com/rust-lang/rust/pull/24920
[RFC 1040]: https://rust-lang.github.io/rfcs/1040-duration-reform.html
[time#136]: https://togithub.com/time-rs/time/issues/136
[chrono#286]: https://togithub.com/chronotope/chrono/pull/286
[chrono#478]: https://togithub.com/chronotope/chrono/pull/478
##### Security advisories
In November of 2020 [CVE-2020-26235] and [RUSTSEC-2020-0071] were opened against the `time` crate. [@quininer](https://togithub.com/quininer) had found that calls to `localtime_r` may 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 to `time`.
On Unix-like systems a process is given a timezone id or description via the `TZ` environment 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. `time` 0.1 and chrono used the POSIX function `localtime_r` to do the conversion to local time, which reads the `TZ` variable.
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 `getenv` in 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 the `TZ` variable or via `iana-time-zone` as 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](https://togithub.com/x-hgg-x). As such, chrono now respects the Rust lock when reading the `TZ` environment variable. In general, code should avoid modifying the environment.
[CVE-2020-26235]: https://nvd.nist.gov/vuln/detail/CVE-2020-26235
[RUSTSEC-2020-0071]: https://rustsec.org/advisories/RUSTSEC-2020-0071
[chrono#499]: https://togithub.com/chronotope/chrono/pull/499
[RUSTSEC-2020-0159]: https://rustsec.org/advisories/RUSTSEC-2020-0159.html
[rust#27970]: https://togithub.com/rust-lang/rust/issues/27970
[chrono#677]: https://togithub.com/chronotope/chrono/pull/677
[tz-rs crate]: https://crates.io/crates/tz-rs
##### 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::Duration` type, 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 `Duration` implementation 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.
[chrono#1095]: https://togithub.com/chronotope/chrono/pull/1095
Thanks to all contributors on behalf of the chrono team, [@djc](https://togithub.com/djc) and [@pitdicker](https://togithub.com/pitdicker)!
### [`v0.4.29`](https://togithub.com/chronotope/chrono/releases/tag/v0.4.29): 0.4.29
[Compare Source](https://togithub.com/chronotope/chrono/compare/v0.4.28...v0.4.29)
This release fixes a panic introduced in chrono 0.4.27 in `FromStr>` ([#1253](https://togithub.com/chronotope/chrono/issues/1253)).
Chrono now has a [Discord channel](https://discord.gg/sXpav4PS7M).
##### Fixes
- Fix arbitrary string slicing in `parse_rfc3339_relaxed` ([#1254](https://togithub.com/chronotope/chrono/issues/1254))
##### Deprecations
- Deprecate `TimeZone::datetime_from_str` ([#1251](https://togithub.com/chronotope/chrono/issues/1251))
##### Documentation
- Correct documentation for `FromStr` for `Weekday` and `Month` ([#1226](https://togithub.com/chronotope/chrono/issues/1226), thanks [@wfraser](https://togithub.com/wfraser))
##### Internal improvements
- Revert "add test_issue\_866" ([#1238](https://togithub.com/chronotope/chrono/issues/1238))
- CI: run tests on `i686` and `wasm32-wasi` ([#1237](https://togithub.com/chronotope/chrono/issues/1237))
- CI: Include doctests for code coverage ([#1248](https://togithub.com/chronotope/chrono/issues/1248))
- Move benchmarks to a separate crate ([#1243](https://togithub.com/chronotope/chrono/issues/1243))
This allows us to upgrade the criterion dependency to 5.1 without changing our MSRV.
- Add Discord link to README ([#1240](https://togithub.com/chronotope/chrono/issues/1240), backported in [#1256](https://togithub.com/chronotope/chrono/issues/1256))
Thanks to all contributors on behalf of the chrono team, [@djc](https://togithub.com/djc) and [@pitdicker](https://togithub.com/pitdicker)!
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ 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.
[ ] If you want to rebase/retry this PR, check this box
This PR has been generated by Mend Renovate. View repository job log here.
This PR contains the following updates:
0.4.28->0.4.30Release Notes
chronotope/chrono (chrono)
### [`v0.4.30`](https://togithub.com/chronotope/chrono/releases/tag/v0.4.30): 0.4.30 [Compare Source](https://togithub.com/chronotope/chrono/compare/v0.4.29...v0.4.30) In this release, we have decided to swap out the `chrono::Duration` type (which has been a re-export of time 0.1 `Duration` type) with our own definition, which exposes a strict superset of the `time::Duration` API. This helps avoid warnings about the [CVE-2020-26235] and [RUSTSEC-2020-0071] advisories for downstream users and allows us to improve the `Duration` API 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](https://togithub.com/chronotope/chrono/pull/1095#issuecomment-1571716955) 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](https://togithub.com/chronotope/chrono/issues/1268). ##### Additions - Add `NaiveDate::leap_year` ([#1261](https://togithub.com/chronotope/chrono/issues/1261)) ##### Documentation - Update main documentation from README ([#1260](https://togithub.com/chronotope/chrono/issues/1260), thanks [@Stygmates](https://togithub.com/Stygmates)) - Add history of relation between chrono and time 0.1 to documentation ([https://github.com/chronotope/chrono/pull/1264](https://togithub.com/chronotope/chrono/pull/1264), [https://github.com/chronotope/chrono/pull/1266](https://togithub.com/chronotope/chrono/pull/1266)) - Clarify `Timelike::num_seconds_from_midnight` is a simple mapping ([#1255](https://togithub.com/chronotope/chrono/issues/1255)) #### Relation between chrono and time 0.1 Rust first had a `time` module added to `std` in its 0.7 release. It later moved to `libextra`, and then to a `libtime` library 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::Duration` was included as `std::time::Duration` ([rust#15934]) in 2014. In preparation of Rust 1.0 at the end of 2014 `libtime` was moved out of the Rust distro and into the `time` crate to eventually be redesigned ([rust#18832], [rust#18858]), like the `num` and `rand` crates. Of course chrono kept its dependency on this `time` crate. `time` started re-exporting `std::time::Duration` during this period. Later, the standard library was changed to have a more limited unsigned `Duration` type ([rust#24920], [RFC 1040]), while the `time` crate kept the full functionality with `time::Duration`. `time::Duration` had been a part of chrono's public API. By 2016 `time` 0.1 lived under the `rust-lang-deprecated` organisation and was not actively maintained ([time#136]). chrono absorbed the platform functionality and `Duration` type of the `time` crate in [chrono#478] (the work started in [chrono#286]). In order to preserve compatibility with downstream crates depending on `time` and `chrono` sharing a `Duration` type, chrono kept depending on time 0.1. chrono offered the option to opt out of the `time` dependency by disabling the `oldtime` feature (swapping it out for an effectively similar chrono type). In 2019, [@jhpratt](https://togithub.com/jhpratt) took over maintenance on the `time` crate and released what amounts to a new crate as `time` 0.2. [rust#15934]: https://togithub.com/rust-lang/rust/pull/15934 [rust#18832]: https://togithub.com/rust-lang/rust/pull/18832#issuecomment-62448221 [rust#18858]: https://togithub.com/rust-lang/rust/pull/18858 [rust#24920]: https://togithub.com/rust-lang/rust/pull/24920 [RFC 1040]: https://rust-lang.github.io/rfcs/1040-duration-reform.html [time#136]: https://togithub.com/time-rs/time/issues/136 [chrono#286]: https://togithub.com/chronotope/chrono/pull/286 [chrono#478]: https://togithub.com/chronotope/chrono/pull/478 ##### Security advisories In November of 2020 [CVE-2020-26235] and [RUSTSEC-2020-0071] were opened against the `time` crate. [@quininer](https://togithub.com/quininer) had found that calls to `localtime_r` may 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 to `time`. On Unix-like systems a process is given a timezone id or description via the `TZ` environment 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. `time` 0.1 and chrono used the POSIX function `localtime_r` to do the conversion to local time, which reads the `TZ` variable. 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 `getenv` in 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 the `TZ` variable or via `iana-time-zone` as 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](https://togithub.com/x-hgg-x). As such, chrono now respects the Rust lock when reading the `TZ` environment variable. In general, code should avoid modifying the environment. [CVE-2020-26235]: https://nvd.nist.gov/vuln/detail/CVE-2020-26235 [RUSTSEC-2020-0071]: https://rustsec.org/advisories/RUSTSEC-2020-0071 [chrono#499]: https://togithub.com/chronotope/chrono/pull/499 [RUSTSEC-2020-0159]: https://rustsec.org/advisories/RUSTSEC-2020-0159.html [rust#27970]: https://togithub.com/rust-lang/rust/issues/27970 [chrono#677]: https://togithub.com/chronotope/chrono/pull/677 [tz-rs crate]: https://crates.io/crates/tz-rs ##### 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::Duration` type, 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 `Duration` implementation 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. [chrono#1095]: https://togithub.com/chronotope/chrono/pull/1095 Thanks to all contributors on behalf of the chrono team, [@djc](https://togithub.com/djc) and [@pitdicker](https://togithub.com/pitdicker)! ### [`v0.4.29`](https://togithub.com/chronotope/chrono/releases/tag/v0.4.29): 0.4.29 [Compare Source](https://togithub.com/chronotope/chrono/compare/v0.4.28...v0.4.29) This release fixes a panic introduced in chrono 0.4.27 in `FromStrConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ 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 Mend Renovate. View repository job log here.