Skip to content
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

css checksum changed and is not installable currently #25344

Closed
zapashcanon opened this issue Feb 25, 2024 · 15 comments
Closed

css checksum changed and is not installable currently #25344

zapashcanon opened this issue Feb 25, 2024 · 15 comments

Comments

@zapashcanon
Copy link
Contributor

cc @zoggy

@zoggy
Copy link
Contributor

zoggy commented Feb 25, 2024

Don't know what happened, release 0.1.0 is the same as 11 months ago: https://framagit.org/zoggy/ocaml-css/-/tags but indeed this has not the same sha512.

The .gitattributes file was modified in january, to ignore the file .header instead of header when exporting, so the only explanation I see is that gitlab uses current version of .gitattributes to create tar archives instead of the version corresponding to the release tag, producing a different archive file. So it seems ok to change the checksums in opam package file.

@mseri
Copy link
Member

mseri commented Feb 26, 2024

@zoggy I have a copy of the tarball with the correct hash: if you can upload it as release artifact and update the url in the opam file, I'd be happy to send it to you. Otherwise I can upload it on the opam-source-archives

@zoggy
Copy link
Contributor

zoggy commented Mar 4, 2024

(sorry for the late answer, holidays...) I think it's better to put the tarball on the opam source archives. By the way, may be having all referenced tarballs of opam packages on this source archive repo would be better ? Is there a way to automatize this ?

@mseri
Copy link
Member

mseri commented Mar 4, 2024

That is just a temporary solutions and very limited by the maximum size of repositories. From my understanding the plan is integrating opam with software heritage and then get the sources directly from there. It may be that this is happening soon let me ping @kit-ty-kate that knows more

@hannesm
Copy link
Member

hannesm commented Mar 4, 2024

FWIW, the tarball is available as https://opam.robur.coop/cache/md5/bc/bc4bdcf47b37c7bd50bf9f31c391dcd2

@zapashcanon
Copy link
Contributor Author

Since a few years, with the work of @rjbou and myself, all packages are automatically archived by software heritage. Moreover, if the SWHID is added to the opam file, opam is also able to fetch the sources from SWH in case they are missing.

The only (IIRC) thing left to do is patching the opam repository with all the SWHIDs.

@kit-ty-kate
Copy link
Member

The only (IIRC) thing left to do is patching the opam repository with all the SWHIDs.

I disagree. Software Heritage is a flawed platform and should not be trusted in my opinion as long as ocaml/opam#5720 is still a problem.

@zapashcanon
Copy link
Contributor Author

zapashcanon commented Mar 4, 2024

I tought this had been clarified. The SWHID is a form of checksum and it is checked by opam when downloading and it is thus as safe to use as a checksum: if the SWHID is the same, the content is the same. We could also make opam-repo check that the added SWHID is initially valid (as it does for checksum I guess).

@hannesm
Copy link
Member

hannesm commented Mar 4, 2024

I have to admit, I appreciate the work on software heritage. I'd still have a better feeling if opam would always check recorded checksums. What is the price? not too much. What is the value? Well, who ensures that software heritage servers are never compromised?

So, the value of locally verifying checksums is that opam can be trusted without any thoughts on software heritage, it's operations etc.

@zapashcanon
Copy link
Contributor Author

zapashcanon commented Mar 4, 2024

I'd still have a better feeling if opam would always check recorded checksums.

As I'm trying to explain, it does, but here the checksum would simply be called "SWHID". You can compute it locally, check that it matches the recorded SWHID etc.

@rjbou
Copy link
Contributor

rjbou commented Mar 4, 2024

The SWHID story is explained in this comment ocaml/opam#5720 (comment).

To complete: As Software Heritage recompute archives from sources, it is not possible to use the original checksum that is given. That's why we rely on swhid given/generated by maintainers & checked by opam repo CI to be sure that we have the good source & opam checks it. There is no blind reliability on SWH servers.

@hannesm
Copy link
Member

hannesm commented Mar 4, 2024

Ah, thanks Raja. I keep on forgetting about the details about swhid.

@zoggy
Copy link
Contributor

zoggy commented Mar 4, 2024

Thanks @hannesm for the tarball.

So hosting tarballs on opam source archive is not the perennial way to go, and SWH is not yet ready. Gitlab does not seem to offer a way to upload tarballs either, except in the repo itself (for example in the public directory, used for the web pages) but I'd like to avoid that. Any other place to upload such arhives ?

@mseri
Copy link
Member

mseri commented Mar 4, 2024 via email

@zoggy
Copy link
Contributor

zoggy commented Mar 4, 2024

But it may be heavier to handle for each new release. I can live with tarballs in the repo, so don't bother, I will add tarballs to lru-cache and css repositories tomorrow and submit a patch for opam files in opam repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants