Comment by jdxcode
the second the hooks modify the code they've broken your sandbox
I think wasi is a cool way to handle this problem. I don't think security is a reason though.
the second the hooks modify the code they've broken your sandbox
I think wasi is a cool way to handle this problem. I don't think security is a reason though.
It depends. I wrote a pre-commit hook (in shell, not precommit the tool) at a previous job that ran terraform fmt on any staged files (and add the changes to the commit) because I was really tired of having people push commits that would then fail for trivial things. It was overrideable with an env var.
IMO if there’s a formatting issue, and the tool knows how it should look, it should fix it for you.
> the second the hooks modify the code they've broken your sandbox
Changes to code would obviously need to be reviewed before they are committed. That's still much better than with pre-commit, where e.g. to do simple things like banning tabs you pretty much give some guy you don't know full access to your machine. Even worse - almost everyone that uses pre-commit also uses tags instead of commit hashes so the hook can be modified retroactively.
One interesting attack would be for a hook to modify e.g. `.vscode/settings.json`... I should probably make the default config exclude those files. Is that what you meant? Even without that it's a lot more secure than pre-commit.