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 988c773acd759dbebc9f2a1c1ebca460a4e6f305 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 ```