Re: [PATCH] [pre-commit] Add shellcheck

[Simon Marchi <simark@simark.ca>]

On 2026-06-18 11:19, Tom de Vries wrote:
> I found a pure python implementation of shellcheck [1].
> 
> Use it to run shellcheck on scripts in the repo.
> 
> Exclude any scripts that are not currently clean.
> 
> Running it seems reasonably fast:
> ...
> $ pre-commit run shellcheck --all-files -v
> shellcheck...............................................................Passed
> - hook id: shellcheck
> - duration: 0.06s
> ...
> 
> For information on other solutions, see this RFC [2].
> 
> [1] https://pypi.org/project/pureshellcheck/0.2.2/
> [2] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html

While I'm sympathetic to the use of pre-commit (I added the first
hooks), I'm starting to get a bit worried that we kind of blindly pull
hooks from random places without paying much attention.  This is going
to get executed on the machines of many GDB devs, and probably some CI
too.

I had this thought because this one has the "random project on github
vibes" (it appears to be a vibe coded project started a week ago).  More
established projects (like black) are not immune to being compromised,
but they are easier to trust I guess.

Assuming you gave a quick look at the code of this project and judge
that it's fine, how can we ensure that whatever pre-commit pulls is what
you reviewed?  We use a git tag, but is that sufficient?  Could a
(malicious or compromised) project publish a tag, and then replaced that
tag with something else later?

An alternative could be to point to a specific commit hash.  A more
radical alternative would be to vendor (put in our repo) the code of the
hooks we use.

I'd like to hear your thoughts on this.

Simon