bump time #639
bump time #639
Conversation
|
Hi, it would be great if this could be merged. What is blocking this PR? |
|
Unmaintenance is blocking it. |
|
@Milo123459 is a maintainer though, no? |
I'm a maintainer, I made this PR. This change is rather large, and CI failing with un-helpful errors due to the way this was set up for Rust 2015 doesn't make it easier. I have emailed the owner of the project, asking him to review and find changes, and he hasn't replied yet. There is simply not much I can do other than fixing CI (which I plan on doing soon). |
|
Thanks for the reply. I'm looking forward to seeing this merged. |
|
can plz update to newest not just min to fix vuln? time at 0.3.7 now https://github.com/time-rs/time these vulns block for me |
|
This creates API changes that the owner (Brandon) doesn't want. |
|
Is that discussion public somewhere? I'd be happy to help think about the required API changes. |
No, it isn't. Sorry. However, I appreciate the offer. |
|
If I add ?w=1 to the URL of this PR, it seems that there are no public API changes done by this PR. Is the objection towards API changes of the time crate? Is the opinion that chrono shall remain on an outdated and insecure time version forever? I hope not? |
|
Brandon doesn't want to change the API AFAIK. The main idea of this is to not change the API, instead to make it so that it patches the vulnerability. That's it. |
|
if chrono refuse to keep deps update and secure what is alt lib that can be use in place? so many open pr for security issue, its not good look look like exploits in wild rustsec/advisory-db#1082 (comment) |
We aren't refusing. We are literally trying to update this dependency to fix the vulnerability. Please re-read what I said, I simply said that I'm trying to fix the security vulnerability; not change the API. EDIT: Sorry about sending it 4 times, GitHub wasn't working so I tried it again, to which it apparently worked. |
|
rise major vers if api is issue to not break others. not good look to still use old vers of dep that may have other issue still. if owner awol/not care then maintainer should just take over and do what need done for good of community and security |
|
for record: if api need change to fix vuln will it or users left insecure when use chrono? |
|
Maybe it's time to fork... It's been months now, and this crate is used everywhere. |
If you want to, fork chrono and make a pull request. It is the lack of communication from the higher ups that is causing so many road blocks. |
450: Get rid of chrono in favor of time r=Kerollmops a=irevoire We only use `chrono` as a wrapper around `time`, and since there has been an [open CVE on `chrono` for at least 3 months now](chronotope/chrono#632) and the repo seems to be [struggling with maintenance](chronotope/chrono#639), I think we should use `time` directly which is way more active and sufficient for our use case. EDIT: Actually the CVE status has been known for more than 6 months: chronotope/chrono#602 Co-authored-by: Irevoire <tamo@meilisearch.com>
2376: Fix security audit - get rid of chrono and use time directly r=AurelienFT a=AurelienFT Chrono still use a very old version of time (0.1 now it's 0.3). They have a PR running since months for updating but it seems that there is communication problems that lead to long time development. The PR : chronotope/chrono#639 This break our CI like a lot of others projects that use `cargo audit`. A lot of projects that use chrono to do things that are now implemented in the new version of `time` has switched to use `time` directly instead of using tokio. Some examples : - brave/brave-browser#20568 - meilisearch/milli#450 So as we also only use chrono to make things that now possible in `time` which is more maintained I suggest in this PR a change to use `time` instead of `chrono`. So that it will fix our CI and make us use a more maintained dependency. Fix #2374 Co-authored-by: AurelienFT <aurelien.foucault@epitech.eu>
ghost
mentioned this pull request
|
I don't think we'll be updating the version of time used in chrono. Since #478, chrono has a minimal dependency on time, and in the next semver-incompatible version we'll remove the dependency entirely. |
Thanks for contributing to chrono!
about adding the PR number)
we can't reintroduce it?