git users, enable fsck by default for better security?

Advice from Nick:
https://lists.torproject.org/pipermail/tor-dev/2016-February/010350.html

How relevant is this for Whonix? Does signed tags make it redundant?

Could be useful for general build instructions however.

Good day,

not sure wether I’m qualified to juge here, though as far as I can tell, what is prevented with this, is rather unlikely to happen during normal usage. That however doesn’t mean that activating such a feature would be a bad idea, I don’t see anything that’d speak against it, only potential benefits.

Have a nice day,

Ego

/cc @marmarek

Spent some time evaluating and testing it and generally it looks like:

  1. It is orthogonal to signed tags usage - tag signs commit ID (its
    SHA-1 sum), but the issue is about corrupted (intentionally or not)
    object, without changing its ID in metadata

  2. Such corruption by default is not detected in fetch phase (git while
    fetching objects does not verify whether its SHA1 sum really matches the
    content)

  3. Corruption is detected in checkout phase. So when you actually want
    to use the sources, it is verified that you really got what you wanted
    (at least it matches given commit ID, potentially signed).

So in practice it doesn’t affect working copy, only parts of repository
somewhere deep in history, or in other branches etc. Enabling this
option is good for repository integrity (detect corruption on transfer),
but isn’t security critical. Hypothetical attacker having access to
remote repository or transport stream can only perform DoS attack, which
he/she can do anyway by simply terminating the connection.

git config --global --add transfer.fsckobjects true
git config --global --add fetch.fsckobjects true
git config --global --add receive.fsckobjects true