CODEWITHSUNDEEP
gitsecuritydeployment
thinke365
thinke365

Reputation: 1335

Security concerns when using git as a deployment utility

git is a very powerful tool, but not that easy to use

For example, I am glad to use git as a tool to update my remote site from my git repository. The problem is there is a .git directory at the root of my website, external users can simply visit it using site/.git, that is terrible, since they can easily get my code history, and basically the current code, they can even get passwords and private informations from the configuration files.

So what is the right way to use git which can make full use of git, but without introducing these threats?

Using git clone git://repo site_root to initialize web site, and git pull to get changes is of great convenience, but also brings huge security problems.

Is there any methods that can be as convenient as the steps shown above, but without security pitfalls?

Upvotes: 3

Views: 2529

Answers (6)

pedromanoel
pedromanoel

Reputation: 3312

I'll resurrect this question because I'm also looking into security issues.

You should use a detached work tree, as explained here. You can create your git repository outside the web root, and have git point to the source code at a different directory.

Upvotes: 0

Gaston
Gaston

Reputation: 1848

If having the complete repo in the production server is a requirement, then there is a solution.

You can have the whole history somewhere in the file system and have git "point" to it.

$ cd /public                        # go to the public directory
$ git clone git://repo              # to initialize the web site
$ mv .git /private/repo.git         # move sensible information to a private place
$ export GIT_DIR=/private/repo.git  # make git "point" to the history
$ git pull                          # update changes

If you do that, your history will be in /private/repo.git that is not accessible through the web, and your working directory will be in /public, serving only the version of the files you specify.

For more information, you can read progit.

Upvotes: 0

lhagemann
lhagemann

Reputation: 1268

A combination of @JaredPar's comment, and @Chris Shain's answer above (+1 for the git archive).

I use git archive also, and then use Chef for the actual deployment. Couldn't be simpler.

  1. git archive <tag_name> | gzip > rc.tar.gz
  2. mv rc.tar.gz to my cookbook
  3. upload cookbook

The chef-client running on my server runs the recipe to copy the zipped file to a chache location and extract it into my web server directory.

Note to self: publish the recipe on github

Upvotes: 0

ceejayoz
ceejayoz

Reputation: 180157

Apache, at least, defaults its configuration to forbidding web access to any file starting with a ., and this could be done in any other webserver as well.

Additionally, it's best to keep sensitive files outside the web root, i.e.:

.git/
config.file
public/
public/index.html

and have the document root for the site be the public/ directory.

Upvotes: 3

Colin Hebert
Colin Hebert

Reputation: 93197

Well, I'm not really fond of using directly git to automatically deploy the last version of your code, but that's another question.

Regarding your security issue, a really basic solution would be to just remove access to your .git file (with htaccess files?).

Another thing would be to remove your passwords from the git repository, there is probably no use of then in your version control system.

Upvotes: 1

Chris Shain
Chris Shain

Reputation: 51369

See http://www.clientcide.com/best-practices/exporting-files-from-git-similar-to-svn-export/

From the above:

Here’s my one-line command for taking the archive and sending it to a different location:

git archive HEAD | (cd ~/path/where/I/want/it/ && tar -xvf -)

This will extract the ENTIRE library to the specified path (without the .git files and whatnot).

Sometimes, however, I want to pull out just a portion of the library. git archive always gives you the whole enchilada which kinda sucks, and in this case I use rsync, like this:

rsync path/I/want/to/export/ -ri --del -m --exclude ".*" ~/path/where/I/want/it/ |grep sT

That last bit – the grep sT will limit the output of what I see so that I only see the files that are updated. I use that just to sanity check my export. If I see a TON of stuff go to update a path that already has the library and I know I only changed one file, then I know I got the path wrong.

Upvotes: 1

Related Questions