Safe-commit-hook: prevent developers from checking in sensitive files
1–9 of 9 posts
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#2Still requires manual effort. We have 100s of repositories at work, and if we were lucky enough to have 100s of developers - they'd all have to do this manually every time.
I've often wondered whether it would be worthwhile for git to include some global configuration to allow global pre/post commit hooks which are opt-out on a per repository basis. If I could do this for every repository our developers created automatically - I would.
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#3Still requires manual effort. We have 100s of repositories at work, and if we were lucky enough to have 100s of developers - they'd all have to do this manually every time. I've often wondered whether it would be worthwhile for git to include some global configuration to allow global pre/post commit hooks which are opt-out on a per repository basis. If I could do this for every repository our developers created autom…
git upstream has rejected that for security reasons; git clone should not produce a repository that runs arbitrary code on the user's system.
However, it seems reasonable to have an explicit option to clone, such as --use-hooks, that allows repositories to enable their local hooks automatically.
Apart from that, you could have a server-side hook that prevents any push containing such files.
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#4Still requires manual effort. We have 100s of repositories at work, and if we were lucky enough to have 100s of developers - they'd all have to do this manually every time. I've often wondered whether it would be worthwhile for git to include some global configuration to allow global pre/post commit hooks which are opt-out on a per repository basis. If I could do this for every repository our developers created autom…
git upstream has rejected that for security reasons; git clone should not produce a repository that runs arbitrary code on the user's system. However, it seems reasonable to have an explicit option to clone, such as --use-hooks, that allows repositories to enable their local hooks automatically. Apart from that, you could have a server-side hook that prevents any push containing such files.
Yes, a server-side hook is basically an arbitrary python/bash/whatever script with access to the commits being pushed. You can enforce anything server-side.
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#5Still requires manual effort. We have 100s of repositories at work, and if we were lucky enough to have 100s of developers - they'd all have to do this manually every time. I've often wondered whether it would be worthwhile for git to include some global configuration to allow global pre/post commit hooks which are opt-out on a per repository basis. If I could do this for every repository our developers created autom…
You just add it to the repo itself. Really not a lot of work. You're a dev... automate it.
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#6Still requires manual effort. We have 100s of repositories at work, and if we were lucky enough to have 100s of developers - they'd all have to do this manually every time. I've often wondered whether it would be worthwhile for git to include some global configuration to allow global pre/post commit hooks which are opt-out on a per repository basis. If I could do this for every repository our developers created autom…
git upstream has rejected that for security reasons; git clone should not produce a repository that runs arbitrary code on the user's system. However, it seems reasonable to have an explicit option to clone, such as --use-hooks, that allows repositories to enable their local hooks automatically. Apart from that, you could have a server-side hook that prevents any push containing such files.
I think the proposal was that a user can create global hooks on their user account. So if you put a hook in ~/.git/hooks, it will act as if it was in $PROJECT_DIR/.git/hooks, unless that specific repository has disabled global hooks.
If you do this, then developers only need to install the hooks once when they set up their machine, and then will already have them when they clone a repo.
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#7Why would you simply rely on extensions instead of, say, also the file's magic numbers?
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#8https://github.com/jandre/safe-commit-hook/blob/master/git-d...
> schema.rb
Don't you kind of need this in a rails project?
Re: Safe-commit-hook: prevent developers from checking in sensitive files
#9https://github.com/jandre/safe-commit-hook/blob/master/git-d... > schema.rb Don't you kind of need this in a rails project?
No, you can make do without it. ActiveRecord will connect to your database and learn about your tables at runtime, and if you want you can choose to think of the combination of all your migrations as the source of truth for your schema.
That said I've seen this done, but wouldn't recommend it. Your schema.rb is helpful to collaborators and running through all of your migrations on a new base is silly.