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.
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
Spent some time evaluating and testing it and generally it looks like:
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
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)
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