replace chrono with newer time #39
Conversation
|
Ah I missed that time was already removed in #37 , this just needs a new release. |
|
Also can you please push the missing tags since 2.5.0? |
|
It's still useful to remove chrono as a dependency, so that |
|
In practice, it looks like thos CVE is of moderate severity. It requires an attacker to control environment variables and not just user input. I'm not saying it's not important, I'm just saying this is not an emmegency. The most obvious option is to release a patch release (2.x.y) of this crate with only the relevant hotfix (79bfa8c). If you are concerned about triggering this (somewhat rare) vulnerability in your code I would suggest applying the fix yourself via a If you are more concerned with security best practices, then I agree this is a concern, but definitely not an emergency. As some context there has been some broader activity around the main |
|
Does release 2.8.1 addresses your problem with Besides this specific security issue (which is now fixed), are there any other advantages in switching from |
Techcable
added
C-Cleanup
JanZerebecki
force-pushed
the
replace-chrono-with-time
branch
from
0fcf8a7
to
9384329
Compare
|
2.8.1 does avoid https://rustsec.org/advisories/RUSTSEC-2020-0071 . But from my quick peek there is no version of chrono available that has https://rustsec.org/advisories/RUSTSEC-2020-0159 fixed and there is no useful feature set of chrono that avoids both. Switching to time does avoid both. An alternative would be to fix the chrono issue, but that is not a quick thing for me. A downside of this PR might be that it uses time 0.2.x while it is already at 0.3.7, but finding the same functionality in the newer version of time was also not quick. |
|
Blegh. Sounds like I guess this probably should be a priority for us. |
|
Interestingly enough, when using Binary sizes with time: 0.3: 798KB |
|
Okay. I updated to time 0.3 and fixed the exception. Before this upgrade,
Also I accidentally force-pushed invalidating all the prior comments (sorry) 😉 |
This is to avoid a potential security issue: https://rustsec.org/advisories/RUSTSEC-2020-0159 AKA CVE-2020-26235
Binary sizes actually shrink compared to master, so
this is strictly an improvement ;)
Binary sizes with time: 0.3: 798KB
Binary sizes with master (using chrono): 816KB
Also this corrects the TIMESTAMP_FORMAT to work with time instead of chrono.
This is specific error caused by the old value of TIMESTAMP_FORMAT ("%b %d %H:%M:%S%.3f"):
> thread '' panicked at 'Invalid specifier .', /Users/techcable/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/time-0.2.27/src/format/parse_items.rs:11:21
when doing `cargo run --example "full-color"`
Techcable
force-pushed
the
replace-chrono-with-time
branch
from
461660d
to
f8f093a
Compare
|
@JanZerebecki let me know what you think about the upgrade to time 0.3 and the new |
|
Thanks. Looks good. |
Right now this is Rust 1.53 This commit doesn't change anything, it just documents what already exists. This was auto-detected by the `cargo msrv` command. Accepting #39 bumped this from 1.38 to 1.53
- Switch from chrono to time (PR #39) - Bump MSRV - Switch from Travis to Github Actions (this PR)
Right now this is Rust 1.53 This commit doesn't change anything, it just documents what already exists. This was auto-detected by the `cargo msrv` command. Accepting #39 bumped this from 1.38 to 1.53
- Switch from chrono to time (PR #39) - Bump MSRV - Switch from Travis to Github Actions (this PR)
Right now this is Rust 1.53 This commit doesn't change anything, it just documents what already exists. This was auto-detected by the `cargo msrv` command. Accepting #39 bumped this from 1.38 to 1.53
- Switch from chrono to time (PR #39) - Bump MSRV - Switch from Travis to Github Actions (this PR)
This is to avoid a potential security issue:
(edit: replaced https://rustsec.org/advisories/RUSTSEC-2020-0071 AKA CVE-2020-26235 with:)
https://rustsec.org/advisories/RUSTSEC-2020-0159 AKA CVE-2020-26235