Security against backward-changes in git?
In particular, is it theoretically possible to make changes to the central (bare; or not) git repository (i.e. having full access to the system it is on) so that the changes do not appear (as a commit) / do not cause conflict on update, but appear in newly cloned repositories?
Or any other similar “forgery”-like change.
No, that’s not possible. Every object in Git is uniquely identified by the hash of its content. That also means that when changing the content, the hash would change, causing it to become a new object which is unrelated to the original object.
So even if you changed some contents, you would have to update its identifier (to make Git accept it) and then you would basically have the same effect as when you rebase things. Other people will get those objects when cloning (e.g. when a branch points on it), but those new objects are incompatible to the original objects causing conflicts.
Git checks the validity of objects when cloning and will inform you if objects are missing/corrupt. You can also force a validation of the local object repository by using git fsck. The output for a changed object would look like this then:
error: sha1 mismatch a98bf3503443ea6a69779fef1f6204fdae913124 error: a98bf3503443ea6a69779fef1f6204fdae913124: object corrupt or missing missing blob a98bf3503443ea6a69779fef1f6204fdae913124