Fix mixed up advisories RUSTSEC-2020-0071 and RUSTSEC-2020-0159 #2285
Conversation
|
@djc can you merge? |
|
First, I think your ping is pretty quick after the initial submission of this PR -- I'm volunteer with many other things to do. Second, it's not obvious to me that this is an improvement. When these issues were discovered I'm pretty sure time 0.3 had already been published for a decent amount of time and so the main usage was via the chrono crate. As such, users who encountered the time 0.1 issue were exceedingly likely to be relying on time 0.1 via chrono. On the other hand, as I recall (as a chrono maintainer at the time), chrono itself contained a different issue that was unrelated to time. Third, again -- why do you care about this? These advisories are pretty old at this point and unlikely to have much of an audience in the future. |
Future researchers of vulnerabilities probably enjoy if facts are straightened even after a long time has passed. This repository is one of the best collections of information to research Rust vulnerabilities. |
It's not like there are factual inaccuracies here, and all of the content is prose, not parsable metadata. Also, my main motivation in volunteering my time to work on this project is to help folks discover vulnerabilities -- not assisting future researchers. |
I spent 30 minutes of my life trying to figure out what was going on with these advisories that were mixed up, that's why |
| 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. | ||
| No workarounds are known. |
There was a problem hiding this comment.
Looking at this again, I agree with @djc that the original text does make sense since it's talking about time as a chrono dependency, and offering workarounds to avoid that, which seems fine to me.
Apologies if I said something else before, I missed this particular bit of context.
This PR was opened as a solution to #2283