Githooks: auto-install client-side hooks inside the repos

https://blog.viktoradam.net/2018/07/26/githooks-auto-install-hooks/

by rycus86 • 8 years ago

42 36 8 years ago

blog.viktoradam.net

I see no discussion of security implications. Of course, frequently if you're cloning a repo you're about to execute out of it anyways, but not always.

bluehatbrit5• 8 years ago

I've not used Go before, but I'm not convinced Go over bash is a benefit in this scenario. It's introducing another dependency and more complexity into the solution, making it less useful for people who don't work with Go. Perhaps it's not aimed at those of us, that's fine but making something less portable to make it easier to build seems like a frustrating trade-off from a user perspective.

Obviously this is an open source side project, so it won't cater to everyone, I'm just skeptical of it being the benefit that it's claimed to be.

prophesi2• 8 years ago

You only need to install Go if you're wanting to manually build the project (which is a good idea for security reasons). You otherwise just add the compiled binary to your path and you're good to go.

He gives his reasonings for it here: https://github.com/git-hooks/git-hooks/wiki/Why-golang

The tl;dr is that it will eventually have features that would be nontrivial to implement with bash, and Go is easier on the development-side than C (coming from a frontend dev experience).

yjftsjthsd-h3• 8 years ago

You would also need the tool chain if you're not on the same platform as built it originally, unless I just skimmed over it outputting multiple binaries and selecting them by local system type. Otherwise I clone a project on my Mac and it tries to run the binaries at the last developer built on her Raspberry Pi.

bluehatbrit5• 8 years ago

Okay that makes sense, thanks for clearing that up for me. That shows my ignorance with Go!

inetknght• 8 years ago

I absolutely do not ever want git to automatically install things when I clone or sync. Copying only.

This is begging for nefarious things to be installed automatically.

mehrdadn4• 8 years ago

I'm less worried about nefarious things and more worried about incompetence. A careless rm -rf ${PWD}/build (or cp or whatever) can nuke/overwrite/etc. my files if it happens inside a folder with a space in it. Because of issues like this I really don't trust anyone to writing scripts that execute automatically on a random machine. Heck, I only barely trust me to do it for myself.

meddlepal• 8 years ago

So you never download and run programs you haven't written or audited?

Nullabillity3• 8 years ago

As much as I agree, this is already an issue with filter in .gitattributes[1].

[1] https://www.git-scm.com/docs/gitattributes

jwilk2• 8 years ago

Filter commands are defined in .git/config, not in .gitattributes.

goerz3• 8 years ago

Something I've done on some projects is to install (or check) the hooks as a side-effect of a script that any contributor is guaranteed to run. In my case, `./configure`. The Makefile would be another place for this (`make test`). It just copies the hooks from `.hooks` to `.git/hooks` and chmods them to be executable. This solves the problem of contributors (or myself) forgetting to set up the proper hooks in every checkout, and it's very low-maintenance.

bluehatbrit5• 8 years ago

Please consider not doing this if you're doing some sort of public / open source work. You're effectively installing software on someone's computer which they may not be directly aware of and that triggers silently in the background. I'm sure you're not nefarious, but if your project were compromised you could easily see issues of downloaded code from the compromise repo being run without the users knowledge.

Internally / privately it's generally a lesser risk, but if this is open source please consider removing that feature for better security. That or document it incredibly clearly.

goerz3• 8 years ago

I don’t see your point. By definition, the build scripts that are part of the repo always execute arbitrary code (e.g. any line in the makefile). Interacting with any compromised repo is always a security risk. Granted, my approach is a bit hacky, but it’s not even modifying anything outside of the checked out folder!

andrethegiant• 8 years ago

For JS projects, I recommend husky: https://github.com/typicode/husky

iBelieve• 8 years ago

Agreed, Husky is great. I like using it with lint-staged (https://github.com/okonet/lint-staged) to run ESLint and Prettier (https://github.com/prettier/prettier).

nmca• 8 years ago

When I've done this before, I just had an "install-hooks" script. What's the need for auto-install?

georgewfraser• 8 years ago

Git hooks are great for formatters, but it's a big problem for large teams that you can't auto-install them on everyones machine. Of course I realize why git refuses to do this. At my company (Fivetran) we ended up writing a Java annotation processor that simply checks if you've installed the git hooks, and if you haven't it throws a big error message that says "YOU NEED TO RUN install_git_hooks.sh"

newur• 8 years ago

That sounds very interesting. Do you have some example code that you can share?

Dunedan• 8 years ago

The solution I prefer is to run all hooks as part of CI as well. So whenever somebody doesn't have them installed locally his builds will just fail if he did something the hooks would've caught.

The next he time he'll think twice if he should wait for the failed CI build or just install the hooks locally.

paulddraper• 8 years ago

I've yet to see a convincing reason for githooks.

Is it not a violation of abstraction to turn your version control system into a build/test/CI system?

Local staging, committing, rebasing, cherry-picking, etc. operate on arbitrary line-delimited text. I should be able to do those without triggering non-VCS things.

Do you want to add a convenient auto format step with your IDE, githooks, or inotifywait? Okay. But changing how a standard, fundamental tool works for everyone...

What's wrong with `make format`?

qznc• 8 years ago

I'm not sure about this at all.

Most checks should be in the CI but git hooks allow a team to add rules without affecting all teams at once. When rules turn out good they can be enforced on everybody via CI. Even a single team might have dozens of machines, so they don't want to roll out git hooks manually.

This is the niche use case I can think of. Still, it exploits git to do things it is not made for. This is asking for trouble elsewhere.

rhoml• 8 years ago

I love this projects because they aim to enforce best practices. I particular like pre-commit.com. Fairly easy to set up and a large variety of plugins already.

Githooks: auto-install client-side hooks inside the repos

Related Stories