-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconsider of chrono crate due to https://rustsec.org/advisories/RUSTSEC-2020-0071.html #134
Comments
As long as we don't enable the But right now, |
Update: |
I don't think we have much control over hitting the vulnerable code paths, but this should be fixed (chronotope/chrono#677) in the next release of chrono. |
It looks like I was fooled by the RUSTSEC advisory into thinking this was about the Luckily, removing duplicate dependencies is a good thing, so my time has not been wasted. |
Yeah and as I've mentioned the next release should fix this. I've went down this rabbit hole when I saw the advisory for the first time and it appears that you're basically screwed since any dependency might cause a conflict by just using the env STD methods. So we could certainly be affected at any time if a dependency introduces a change, considering that we're using threading heavily. But since chrono is currently in the process of releasing a beta, I'd hope we can expect the next proper release within a couple days/weeks. |
The CVE has been revoked (since technically So that should solve all the issues with |
I don't we hit the vulnerable code paths, and if we do, we don't use set_env, though we can't make transitive guarantees about crates we consume.
I think we can probably use the time crate ( v > 0.3 ) for our needs. Maybe?
The text was updated successfully, but these errors were encountered: