add means to verify at build/run-time that source tarball is not tainted - Redmine #2128

Builds from a dev tree identify and record in their version string the exact source version (if possible). However, checking the integrity of the source release either at compile- or runtime is hard, but quite relevant. Use-cases where detecting changes would be useful:

- The user intentionally applies changes to the code (e.g. patch-based software distribution like PLUMED). The resulting binaries will however report vanilla version despite the tainted source (unless explicit efforts are made to change the version string too);

• A user downloads the tarball, tries out a modification leaving the vanilla-looking tree behind. Later this tree can accidentally end up used to build and install a .

One solution could be to generate and distribute a checksum with the source release. This could be re-generated at build-time (excluding the checksum file itself) which would allow compile-time warnings to be issued as well as the result of the verification to be encoded in the binary. This would allow that in both of the above use-cases the -version and log outputs to report e.g. 2016.2-tainted in case if the checksum does not match

(from redmine: issue id 2128, created on 2017-03-02 by pszilard, closed on 2019-11-01)

• Changesets:
  • Revision 988c773a by Paul Bauer on 2019-11-01T07:38:52Z:

Add validation of tarball builds

Allows validation of GROMACS builds against a file stored in the
release tarball to give users an indication if the source they are using
is actually unmodified from the release version.

This only applies to builds from tarballs, as the git version checking
already does all of this for us.

Hash can be generated by the new cmake target checksum-files, and applies
for files in src/ and python_packaging/, if they are included in
a whitelist defined in the script.

Refs #2128

Change-Id: Ia3bc41c0d0566993166f567409510cf9c9ec2020