What do you think about extending version to optionally accept a tuple of old hashes, like:. For instance we could warn users that they have a mirror that is out of sync but still "trusted" , and they need to update it. Seems like the solution is always to remove the old file -- why not just do that and force a re-download? We could prompt before removing. We could also add an option to force a new download to spack install and suggest it -- wouldn't those be easier?
If we don't record deprecated hashes we could potentially loose a tiny bit on the reproducibility side, and maybe that could be worse for people working on air-gapped systems if they are stuck with an old tarball and need to wait for some authorization? The other thing it could enable in the future is a check at install time of the status of an installed package.
That could permit warning users that the version X. Z they are using changed in some way and maybe they want to reinstall. All that said, nothing of the above is a game changer, and there should be a 5 min. If you think it's worth it, I can implement the functionality in There is always the --no-checksum option for people who know that the archive they have is good.
We warn people about it, but this is kind of what it's there for. We could put some clear guidance in about when to use it when these situations arise. I worry about training people to use it too much, though. All of my releases are tagged and known to work, when things like this happen there are just some points in time where you can't check out the trees and build.
No one ever checks out arbitrary points in time though, so it's not a show stopper. The deprecated approach would avoid an element of surprise, when I see a build fail because a digest doesn't match and I wonder whether someone's been hacked or I think alalazo is being too generous with his 5-minute ban. I'd go for a solid 15 although in this case, GitHub did it to the developers However, If I understand the underlying philosophy correctly: If its not a hashable object, than there it cannot be trusted and you must do a --nocheck-sum?
Confused about what the issue is. Copy link. This comment has been hidden. Sign in to view. We couldn't reproduce your issue all the assertions passed on master. I don't know why this was marked unreproducible , because it's very easy to reproduce: [Linux] add a dependecy from github [Linux] commit yarn.
I think it is a problem with yarn. There isn't a way to disable this build at the moment, so the fix would be one of those: Make your build independent from the machine that builds it. I'm able to reproduce this using yarn 3. This is the scenario: Package A is being used with a git url. Checksums don't match, and there is an error code YN Can this issue be re-opened?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment. Linked pull requests. You signed in with another tab or window.
Reload to refresh your session. You signed out in another tab or window. Environment if relevant please complete the following information : OS: macos Being able 'just' to download the repository content as a zip or tar. McFoggy I see your point, but it is a release scenario nonetheless.
Your idea on using the commit timestamp I think it a good solution to this. The functionality your are using is just a download feature of some source code extracted from a git repository on a given commit. In no way it is a release feature. But It can be an enhancement to say that the archive exposed via the download functionalities take the modification date of the commit they represent ; I would assume this can be a good compromise.
I've had a look at the zip archive solution, and similar to ritschwumm solution for tar. This is a JGit issue. Fixed in JGit 4. Skip to content. Star 8. I would have expected it not to change. Since today, the shasum for the tarball is 6ae0ceb37d02fe0dfe7acacef33da1ebd78b6eac.
What is happenning? The text was updated successfully, but these errors were encountered:. I don't know. We don't create these archives ourselves, they're automatically generated by GitHub.
Presumably the results of these are cached, but I don't think that there's a guarantee there. That means that they're not stable. The tar archive itself should be reproducible, but gzip does not have any guarantees of determinism. It uses a timestamp in the header, for example, and of course compression levels will cause wildly different outputs.
The tag for 0. If you want to continue downloading the archive, I would encourage you to take the shasum of the. I would expect that to be stable. But as to why this changed suddenly, I don't know. I suspect it was an otherwise harmless cache invalidation. But I don't like that this happened. It would be ideal if GitHub's codeload would allow for repeatable builds here, and strip the timestamp out.
As for how to make sure this doesn't happen again, I'm not sure yet. I think that we can upload our own artifacts when we do a release. But I'm not sure that disables the automatic. Sorry, something went wrong. Tarballs generated by git have never been guaranteed to have the same checksum as any other tarball. It also depends on what exact version of gzip exists on the host. If your system depends on tarballs which are generated by git on the fly, it has always been prone to arbitrary checksum mismatches.
This bites each project which does this sooner or later. It's bit the Linux kernel and Homebrew in the past. The only way to get consistent checksums is to generate the archive once and upload it somewhere. This is where e. GitHub's releases come in, which let you upload your own artifacts. I believe the Homebrew project upload their source archives to a third party. Distributions such as Debian also upload tarballs to their own servers rather than rely on the project itself hosting them.
As to why this has happened now, GitHub recently completed an OS upgrade on its fileservers, but the most likely cause here is a bugfix to git so the generated tarballs are compatible with more versions of tar on different OSs.
This fix has already been reverted once because it changed the checksums which some projects had been relying on. I believe those projects have now moved to store the archives they want to keep checksums of.
0コメント