I have also been working on an alternative written in Rust, but in my version the hooks are WASI programs. They run on a virtual filesystem backed by the Git repo. That means a) there are no security issues (they have no network access, and no file access outside the repo), b) you can run them in parallel, c) you can choose whether to apply fixes or not without needing explicit support from the plugin, and most importantly d) they work reliably.

I'm sure this is more reliably than pre-commit, but you still have hooks building Python wheels and whatnot, which fails annoyingly often.

https://github.com/timmmm/nit

The VFS stuff is not quite finished yet though (it's really complicated). If anyone wants to help me with that it would be welcome!

▲

jdxcode 6 hours ago | parent [-]

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.

▲

timhh 4 hours ago | parent | next [-]

> 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.

	▲	jdxcode 38 minutes ago \| parent [-]
		You will execute code before you commit it. Maybe not always, but often enough. You will also have lints on things like build scripts. I agree it’s better, but not because of wasi

▲

accelbred 4 hours ago | parent | prev [-]

I wouldn't want hooks modifying the code. They should be only approve/reject. Ideally landlock rules would give them only ro access to repo dir