TYPO3 Core

The also needs to be a tool for generating this hash information.

1. Release creation
2. Developers which need to modify things and want to "sign" the state

@Markus:
IMHO your second point is dangerous as it hides any changes:
every following check of the checksums would return 'no changes done' which is correct and not correct.

correct: no changes after the last checksum calculation,

but as it does not change the original source (at typo3.org) it also is

not correct: there are changes compared to the original files (from typo3.org)

and it is obvious that a tool is neccessary which generates the checksums for a new release so the checksums can be compared lateron

I guess we need two checksums then. One that signs the original Core and one that can be used by agencies to sign their modifications.

It's not so obvious these tools are there. For instance AFAIK there's never been an official tool to create the md5 checksums for the former emconf checksums.

Although I understand the benefits of a check if core files have been modified, this should not be done by the core itself.

This would be a pointless exercise from a security perspective. If an attacker manages to tamper with the core files, the attacker is also able to modify the integrity check to hide or obscure his/her activity (and the fact that the core has been modified). Showing a message "the core files are unmodified" (or modified) gives an administrator a (possibly false) impression that the instance is secure.

Therefore, integrity checks should only be executed from the outside.
I have not tested any existing tools against the TYPO3 core files yet, but there is a range of open-source software security and data integrity tools available.
For example tripwire