CoCoA » CoCoALib

1. generate TARGZ file (maybe also TAR.XZ which is usually smaller)
2. run sha -a 256 TARGZFILE and store the resulting output
3. upload TARGZ file to server, and revise links on the website
4. upload the CHECKSUM, and put it on the website (the checksum should be easy to download/copy-and-paste)

Here is what the BOOST people do:

https://www.boost.org/users/history/version_1_72_0.html

We should probably also produce SHA-256 checksums for the compiled versions too -- use shasum -a 256 -b for binary file!!

I have just stumbled across "GPG" signatures for software. There is a description at https://www.gnupg.org/gph/en/manual/x135.html

I do not know what the relative pros and cons of GPG compared to SHA are...

PS I encountered the GPG signatures on the website https://julialang.org/downloads/

I suppose the GPG signatures give a better guarantee of correctness.

Probably we should try both ways, and see how easy it is for a user to do the check (and how easy it is for us to generate the "signature").

Florian has reported a problem with our being "naughty" about making a new release without changing the version number.

Apparently there is an Arch Linux package for CoCoALib (and maybe CoCoA?) which maintains a link to our download page, but which also includes an SHA checksum of the file (to guard against corrupted/hacked TGZ files).

Currently the Arch Linux package system reports CoCoA as being hacked because the SHA checksum was calculated with one version of the TGZ file, but then we changed the file without changing the release number.

Anna confirms that she has shasum on her computer.

The main question remaining is how to use the SHA sum in a sensible way (i.e. such that it gives some assurance of integrity).

My idea in comment 8 is not so clever... well, the SHA cannot be inside the TGZ file.
Just put it on the website in a place where it is perfectly clear to which file it refers.
It is also possible to make the SHA-256 checksum available as a separate download; but if this is on the same server as the TGZ file (very likely) then this does not really offer any extra security, since if a hacker can change the TGZ file, then it should be easy to change the SHA file too.

If we want to do this, we should delay the release a few days, so we can find out what to do.

I think I might be slightly confused. What I wrote above in comments 11 and 12 actually refers to the "binary" release.

Do we have a script that makes the source TGZ release?

adjusted the page and the release-xxx.sh file to produce the correct files and instructions for publishing.

I suggest putting the SHA-256 checksum in the "Notes" section on the web page for source releases.
Probably the best place is just before the usual release notes: those who don't care about it, can easily skip over it; those who do care, will see the checksum immediately.

John Abbott wrote:

I see that the SHA cecksum is in the "version" column; I think it might be more readable in the "notes" column.
Is that relatively easy to achieve?

easy to achieve, but difficult to maintain ;-)
I prefer to leave it there, I know the line is long, but it also make more sense closer to the file it refers to

Perhaps I'll ask Bruns for his opinion.