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

[Tom de Vries <tdevries@suse.de>]

On 6/18/26 7:05 PM, Simon Marchi wrote:
> 
> 
> 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,

Yeah, I did, that is, I cloned the github repository, checked it out at 
main/v0.2.2, and asked claude code to review it on safety aspects.

> how can we ensure that whatever pre-commit pulls is what
> you reviewed?

The mechanism to get the tool proposed in this patch is via pip.  The 
pypi index mentions the github repo as source, so I'm relying on that.

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

I suppose it's possible.

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

Yeah, that is safer.  It would mean though using github as the source. 
But the repo as is doesn't have pre-commit hooks.  I worked around that 
before by using my own github account (see commit 7f6c7a5bb37 
("[pre-commit] Add tclint hook")).  I'll submit a v2 shortly that uses 
this approach.

FWIW, I'm open to any other solutions.

Thanks,
- Tom

> I'd like to hear your thoughts on this.
> 
> Simon