A recent trend in open source projects seems to be to avoid releasing proper release archives (whether signed with GPG or not). Instead people add Git tags for release commits and call it a day.
A long and arduous debate could be had whether this is "wrong", "right" and whether Git hashes are equivalent to proper tarballs or not, or if --depth=1 is a good thing or not. We're not going to get into that at all.
Instead I'd like to kindly ask that all projects that do releases of any kind to provide actual release tarballs for the following two reasons:
- It takes very little effort on your part.
- Proper release archives make things easier for many people consuming your project.
What about Github automatic archive generation?
Github does provide links to download any project commit (and thus release) as an archive. This is basically a good thing but it has two major issues.
- The filenames are of type v1.0.0.tar.gz. So from a file name you can't tell what it contains and further if you have two dependencies with the same version number, the archive files will have the same name and thus clash. Murphy's law says that this is inevitable.
- The archives that Github generates are not stable. Thus if you redownload them the files may have different checksums. This is bad because doing supply chain verification by comparing hashes will give you random failures.
A simple webui-only way to do it
If you don't want to use git archive to generate your releases for whatever reason, there is a straightforward way of doing the release using only the web ui.
- Create your release by tagging as usual.
- Download the Github autogenerated tarball with a browser (it does not matter whether you choose zip or tar as the format, either one is fine).
- Rename the v1.0.0.tar.gz file to something like myproject-1.0.0.tar.gz.
- Go to the project tags page, click on "create a new release from tag".
- Upload the file from step #3 as a release file.
"The latter might get fixed if Github changes their policy to guaranteed reproducible downloads. The former problem still exists."
ReplyDeleteThe former might get fixed if Github changes their policy/system to generate the filename as -?
> The filenames are of type v1.0.0.tar.gz. So from a file name you can't tell what it contains and further if you have two dependencies with the same version number, the archive files will have the same name and thus clash. Murphy's law says that this is inevitable.
ReplyDeleteActually, they do have detailed names, but only in the HTTP Content-Disposition header. Try curl -fLOJ https://github.com/mesonbuild/meson/archive/refs/tags/0.63.3.tar.gz and you'll see what I mean.