reduce scope of 'chrono' dependency

this is a interesting one, sort of a proof of concept of #57

cargo-deny has identified a known vulnerability in the chrono crate, and suggested a workaround.

the logs from #57:

error[vulnerability]: Potential segfault in the time crate
   ┌─ /github/workspace/Cargo.lock:38:1
   │
38 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
   │ ----------------------------------------------------------------- security vulnerability detected
   │
   = ID: RUSTSEC-2020-0071
   = Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
   = ### Impact

     Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

     The affected functions from time 0.2.7 through 0.2.22 are:

     - `time::UtcOffset::local_offset_at`
     - `time::UtcOffset::try_local_offset_at`
     - `time::UtcOffset::current_local_offset`
     - `time::UtcOffset::try_current_local_offset`
     - `time::OffsetDateTime::now_local`
     - `time::OffsetDateTime::try_now_local`

     The affected functions in time 0.1 (all versions) are:

     - `at`
     - `at_utc`
     - `now`

     Non-Unix targets (including Windows and wasm) are unaffected.

     ### Patches

     Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.

     Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.

     Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

     ### Workarounds

     A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.

     #### Examples:

     `Cargo.toml`:  

     ```toml
     chrono = { version = "0.4", default-features = false, features = ["serde"] }

 ```toml
 chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
 ```

 Commandline:  

 ```bash
 cargo add chrono --no-default-features -F clock
 ```

 Sources:  
  - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-124214[9](https://github.com/serverlesstechnology/cqrs/actions/runs/4391890163/jobs/7691322829#step:4:9)249)  
  - [vityafx/serde-aux#[21](https://github.com/serverlesstechnology/cqrs/actions/runs/4391890163/jobs/7691322829#step:4:21)](https://github.com/vityafx/serde-aux/issues/21)

= Announcement: https://github.com/time-rs/time/issues/293 = Solution: Upgrade to >=0.2.23 = time v0.1.45 └── chrono v0.4.23 └── (dev) cqrs-es v0.4.8



It's a trivial issue, since it's a dev dependency anyway. Still, it's a good advertisement for cargo-deny

serverlesstechnology / cqrs

reduce scope of 'chrono' dependency #58

Codecov Report