Remove chrono dependency in favour of time crate #26

2021-10-20T09:54:22-07:00

Adam-Gleave commented

2021-10-20 09:54:22 -07:00

(Migrated from github.com)

The recent flagging of RUSTSEC-2020-0159 seems to be making cargo audit grumble everywhere about the inclusion of chrono in the dependency tree. While this crate uses chrono in a sound manner, there is unfortunately no way that cargo audit can detect that it's not using any of the features that cause the issue.

time has been updated recently to include a lot of the features that chrono originally included exclusively, so it's possible to remove chrono entirely and replace it with something more sound, as chrono seems to be either inactive or currently unmaintained.

Our CI is flagging this crate up in cargo audit, (since it is a dependency of jsonwebtoken), and this fix should deal with the problem by replacing chrono entirely with the new time version 0.3. Unfortunately, this does change the public API of the crate.

All tests are passsing and fuzzing seems to be running with no issues. I have changed some of the code around UtcTime and GeneralizedTime types to be more compatible with RFC5280 and the time formatting API, which is a little bit of a pain around short year strings.

Is it possible to make this change for a new minor version of this crate? It would be very helpful!

The recent flagging of RUSTSEC-2020-0159 seems to be making `cargo audit` grumble everywhere about the inclusion of `chrono` in the dependency tree. While this crate uses `chrono` in a sound manner, there is unfortunately no way that `cargo audit` can detect that it's not using any of the features that cause the issue. `time` has been updated recently to include a lot of the features that `chrono` originally included exclusively, so it's possible to remove `chrono` entirely and replace it with something more sound, as `chrono` seems to be either inactive or currently unmaintained. Our CI is flagging this crate up in `cargo audit`, (since it is a dependency of [`jsonwebtoken`](https://github.com/Keats/jsonwebtoken)), and this fix should deal with the problem by replacing `chrono` entirely with the new `time` version 0.3. Unfortunately, this does change the public API of the crate. All tests are passsing and fuzzing seems to be running with no issues. I have changed some of the code around `UtcTime` and `GeneralizedTime` types to be more compatible with [RFC5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5.1) and the `time` formatting API, which is a little bit of a pain around short year strings. Is it possible to make this change for a new minor version of this crate? It would be very helpful!

👀 1

acw commented

2021-10-20 10:11:03 -07:00

(Migrated from github.com)

Absolutely! Thanks for the heads up and the patch. This is now merged and published to crates as version 0.6.0. (0.5 -> 0.6 to reflect the API change.)

❤️ 1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: acw/simple_asn1#26

Remove chrono dependency in favour of time crate #26

Remove `chrono` dependency in favour of `time` crate #26