Please turn off default features for chrono dependency

[scouten-adobe]

Running cargo deny on this crate shows that the transitive dependency through chrono crate yields a security advisory. Being more selective about the required features as shown in the warning text below should address that concern.

error[A001]: Potential segfault in the time crate
    ┌─ /.../cryptography-rs/Cargo.lock:155:1
    │
155 │ 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-1242149249)
       - [vityafx/serde-aux#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.24
          ├── cryptographic-message-syntax v0.22.0
          ├── pgp v0.9.0
          │   └── pgp-cleartext v0.6.0
          ├── pgp-cleartext v0.6.0 (*)
          └── x509-certificate v0.19.0
              └── cryptographic-message-syntax v0.22.0 (*)

[scouten-adobe]

This is fixed in #12. Please merge and release a new version or LMK if you have objections.

[indygreg]

Fixed.