Hm, yeah ok, should really be careful with that "I trust the developers of this repo" button (or whatever it says)
100%
I know a guy that considers git pre-commit hooks a form of code injection and thus a security risk. So he disables them on repos he works with. And to be fair, it’s absolutely a viable vector for attacking developer machines. I think a tasks.json fits into that exact same bucket.
These kinds of automations are suuuper useful and I do like to use them. But also review a code base before cloning!
Yeah, it's a little insane to me to automatically run code that exists in a file in the current directory, by default.
Like there's a reason that direnv
requires you to execute direnv allow
if you enter a directory with an .envrc
that you hadn't previously approved.
I don't know of any other editor that has this as standard behavior, and for good reason.
Pre-commit hooks aren't committed to the repo though. What's to disable? Unless it's something like python's precommit module I guess
The configuration is often committed to the repo. And some repos heavily rely on the precommit actions running before you can push or have pipelines function correctly
You'd still need to manually install the git hooks though, the .git folder isn't part of the repo
I mean... You're probably going to run the code in the repo eventually anyway right? At least in the majority of cases. Tbh I don't think it really changes the threat model significantly.
Can't wait to see CVEs popping up exploiting this feature
VS Code