Hacker News Reader

Comment by bluehatbrit | Hacker News Reader

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.

View on HN

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!

My point is, by auto-installing hooks it's making a predictable command, unpredictable. As a user I would not be able to happily run git commands in a repo after a git clone until I've reviewed any hooks that may have been installed. If a user does not review those scripts then it's a security flaw, if a user always review them then it's getting in the way more by forcing someone to do that on every clone.

Build scripts are explicitly called by a user, a git hook is a side effect they've elected to setup. In this case the tool is adding side effects to commands without the user explicitly choosing to have them.

I can see someone downloading a repository, running a few git commands to make a couple of changes and not realising the git hooks have been installed and the behaviour of a command has changed. Once you're near that scenario, you're just opening up security holes rather than fixing them. It'd be better to have a script one can run after a git clone explicitly that is documented in the project repository.

"To setup git hooks to speed up development, run ./init-hooks." is easy, clear, makes it difficult to do it without knowing what's happening.

I guess a good alternative is to have the build tools refuse to do anything until the user/developer has installed the proper hooks by running ./init-hooks (as opposed to executing ./init-hooks silently in the background). I agree that's a preferable way to do it in a public project: explicit is better than implicit

I agree, that sounds like a much better approach. In a private or companies internal project it's probably not an issue, you already "trust" the code you're downloading.

I tend to have some sort of setup or bootstrap script which the docs promote as the way to prepare for development. This tends to install any dev dependencies and also sets up hooks (which is always optional). This works fairly well in most cases, combine that with a lint on the CI and most people don't have any problems. It also saves assuming someone wants git hooks just because they're pulling code, often they just want to build and run it.

Reply on news.ycombinator.com