This is not the first attack I read about on here that involves git hooks. IMO the implementation is kind of insane and lends itself very well to this kind of attack. git basically treats the local .git directory as trusted probably because it believes that git repositories can only come from a clone (or init) operation, which has additional checks for hooks, but as we see here that is not always the case!
I don’t like git hooks in general but I think a better trust model would look similar to direnv’s. .envrc files must be explicitly allowed for them to run, and the hashes of the file and path of allowed .envrc files are stored in an allowlist in .local/share/direnv, which is (generally) outside of the bounds of any repo. It’s not perfect: if the .envrc file contains use flake you won’t get another prompt when the flake.nix file changes, but I think it’d be a reasonable improvement.
This is not the first attack I read about on here that involves git hooks. IMO the implementation is kind of insane and lends itself very well to this kind of attack. git basically treats the local
.gitdirectory as trusted probably because it believes that git repositories can only come from aclone(orinit) operation, which has additional checks for hooks, but as we see here that is not always the case!I don’t like git hooks in general but I think a better trust model would look similar to direnv’s.
.envrcfiles must be explicitly allowed for them to run, and the hashes of the file and path of allowed.envrcfiles are stored in an allowlist in.local/share/direnv, which is (generally) outside of the bounds of any repo. It’s not perfect: if the.envrcfile containsuse flakeyou won’t get another prompt when theflake.nixfile changes, but I think it’d be a reasonable improvement.score 1 · canonical
There is a feature on direnv main for this, marking files as changes require reallow. But they haven’t cut a new release since it was merged.
score 1 · canonical