-
Notifications
You must be signed in to change notification settings - Fork 601
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
Add timestamp validation to tarball files #3859
Comments
I'm not sure how we'd be able to tell if it's incorrect or not. 1970 sure sounds wrong, but where is the threshold? |
2000 would be probably good enough. |
maybe, but I'm not sure what the difference is between 1970 being wrong and 2000 being wrong 🤔 |
Avoid some Debian errors like: |
As described in rust-lang/crates.io#3859, the current arbitrary timestamp of 123456789 leads to Debian packages being auto-rejected due to the old timestamp. This happens for any timestamps before 1975. Instead of 123456789, use another, more recent arbitrary timestamp -- the timestamp of the first commit for what would become Rust. graydon/rust-prehistory@b0fd440
As described in rust-lang/crates.io#3859, the current arbitrary timestamp of 123456789 leads to Debian packages being auto-rejected due to the old timestamp. This happens for any timestamps before 1975. Instead of 123456789, use another, more recent arbitrary timestamp -- the timestamp of the first commit for what would become Rust. graydon/rust-prehistory@b0fd440
Enforce to use tar v0.4.38 The latest version of `tar` crate includes alexcrichton/tar-rs#262, which uses a bit recent timestamp when archiving. However, [it seems rust-lang/rust uses v0.4.37](https://github.com/rust-lang/rust/blob/e0944922007e1bb4fe59809293acf4364410cccc/Cargo.lock#L5124-L5132). This PR enforces to use v0.4.38 and it would _fix_ rust-lang/crates.io#3859 eventually.
I've made Cargo use tar v0.4.38 which includes alexcrichton/tar-rs#262, but some files still have 1970-01-01 including Cargo.toml:
Maybe some files' |
While I think it's reasonable to prefer a newer timestamp, I'm not sure if we should validate and reject it on crates.io. If I understand correctly, it would reject many old Cargo versions, no? |
yeah, I tend to agree. we shouldn't reject these files, but we should ideally fix this on the |
Describe the bug
If I have my history correct, it is quite unlikely that we have any Rust file written during the 1970 years, we should have files with timestamp from these years.
To Reproduce
Expected behavior
crates.io should probably reject incorrect/invalid timestamps
(it is causing pain the Debian packaging side)
It was probably caused by:
rust-lang/cargo#9512
The text was updated successfully, but these errors were encountered: