Dealing with unsoundness in chrono

[djc]

Hey, have you decided what you want to do with the chrono issues?

https://rustsec.org/advisories/RUSTSEC-2020-0159

Maybe it makes sense for rcgen to just adopt time 0.3 instead?

[est31]

Thanks for bringing this to my attention. And omg is the chrono thread spammed with links to bug reports. The time crate has less dependencies than chrono, so maybe switching to time is a good idea. It also seems to be more popular at least according to the recent download counts.

[est31]

Another proof that adding dependencies doesn't absolve you from maintainer duties, in fact they get expanded. You suddenly are responsible for bugs that are in a part of a library that you don't even use (you only use the library).

[djc]

chrono depends on time 0.1 IIRC, so I'm not sure the difference in recent download counts is meaningful.

[est31]

@djc I use download counts as proxy for ecosystem compatibility. The main reason I'm using a date library is because I don't want to burden users with converting back and forth but be able to just put in dates that their library supports.

[est31]

There is also the issue of asn.rs using chrono, so it has to switch as well I guess?

[makr11st]

@est31 Hi, is there an update on #66 it seems the PRs in deps are now merged.

[est31]

The time crate does not support leap seconds, see time-rs/time#193 . This can be an issue for certificate generation libraries as single seconds can become important in the security domain. So I'm a bit reluctant, because rcgen does not use the offending function that makes chrono unsafe in the database, but it does rely on leap second support. The PR #66 has to change some of the unit tests that check for leap seconds.

Ultimately, if there is no movement on the time crate, I think I'll just merge it as is and accept the regression.

[est31]

Alright, when the new ring version will be released, I'll switch to time: briansmith/ring#1416 (comment)

[makr11st]

No worries and no pushing, just was wondering if there were additional dependencies you were waiting for, it makes sense to implement proper leap seconds handling. I saw the leap second discussion in the other repos, but it doesn't seem like a straightforward problem to solve.
Thanks for replying.

[est31]

Hmmm no changes for ring. There seems to be progress on the chrono front though: chronotope/chrono#632 (comment)

[est31]

Also: chronotope/chrono#639

[makr11st]

Thanks for the merge and release.