32

Say I cloned a repo, then maybe worked on it a bit. Then I reverted/pushed all changes, so my friend has all the repo files. Is it safe for me to send him the .git folder? Is there any private information there, such as my username, my email, command history, or perhaps some secrets?

Paul
  • 583
  • 5
  • 8
  • 7
    If you have pushed all of your changes, why can't your friend access those changes from the place you pushed them to? Shouldn't they be able to clone, too? – jpaugh Apr 02 '21 at 19:31
  • @jpaugh it's just a simple made-up story. In reality there can be several reasons, e.g.: The folder was sent as part of a larger archive of files or disk-on-key. Or, there are commits which weren't pushed that I want to send as files. Or, maybe I have an open source website and I wonder whether having .git accessible is OK. etc. – Paul Apr 02 '21 at 19:46
  • 2
    Ok. I recommend you get your push/pull process down, so that you and your teammates can rely on it, rather than having to use special cases. Of course, there are (the same) security concerns with the normal push process. – jpaugh Apr 02 '21 at 19:48
  • If you don't want to push something into your main development or production branches, you could push to a new branch called paul/wizbang-feature, and ask your friend to pull from there. There are tools like Git Flow which help you standardize the way you work with branches in a team, to help with situations like this. – jpaugh Apr 02 '21 at 19:50

3 Answers3

67

The contents of your .git repository may contain loose objects that you may not want to share (e.g. something you committed but changed your mind and deleted/amended), so there is no definite "yes, this is safe."

A better way to share git repositories offline is to create a bundle file and send that to your friend, e.g.:

git bundle create /tmp/myrepo.bundle --all

Then you can send myrepo.bundle to your friend and they can clone from it like they would from any remote:

git clone myrepo.bundle 

That would be a better way to make sure that you're not sharing loose objects that aren't intended to be seen by others.

mricon
  • 6,238
  • 22
  • 27
  • 4
    That's a good strategy. People forget that `git clone` will grab the *entire history*, not only the recent view of the files... – ThoriumBR Apr 01 '21 at 21:19
  • 21
    @ThoriumBR as opposed to git bundle, which also grabs the entire history, and not only the recent view of the files? The only difference is with dangling commits, AFAICT. – Eric Duminil Apr 02 '21 at 18:43
  • @ThoriumBR That's good to keep in mind, in general. You can use the [--depth](https://www.git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt) parameter to make a shallow clone, but shallow clones are much more limited in what you can do with them. – jpaugh Apr 02 '21 at 19:33
  • 2
    @EricDuminil, and the reflog and the config. Those might be more important than the lose objects. – Jan Hudec Apr 03 '21 at 12:54
  • @JanHudec: If bundle includes the reflog, does it mean that dangling commits are included too, and that there is no difference at all between a clone and a bundle? So a bundle would just be a 2-step clone? – Eric Duminil Apr 03 '21 at 17:36
  • @EricDuminil, the bundle does not, as far as I can tell, contain the reflog. Only the explicitly referenced refs and the revisions reachable from them. – Jan Hudec Apr 04 '21 at 11:23
  • @JanHudec okay, thanks, i misunderstood your original comment. – Eric Duminil Apr 04 '21 at 11:29
18

Is it safe for me to send him the .git folder?

One place you would need to be careful is that sharing your entire .git folder would include .git/config. Depending on what you've done, this could have very little information, or quite a lot. If all you've done is a clone, there won't be much more than your list of remotes. If you've worked extensively in the repository, however, there might be things like aliases or configuration settings, as well as a partial record of what branches you've pushed (more specifically, what tracking branches you have configured). Worse, if you've set up any access credentials (e.g. for code review or CI) that are stored in the local .git/config, those would be leaked.

Beyond this, see the other answers.

All that said, however, I don't believe you would need to send the .git/config anyway. However, sending a bundle is going to be much safer, as well as more reliable, so the short answer is that you just shouldn't send your .git folder in any case. Not just for security/privacy, but for ease of use also.

Is there any private information there, such as my username

Your local machine username should only be present in a repository if you have not configured your git identification. In this case, git defaults to something like $(id)@$(hostname), which will be recorded if you commit anything. This might be especially relevant if you commit something, realize you need to set your identification, and amend the commit, as the old commit may still be present until it gets garbage-collected.

my email

Your e-mail is part of a git commit's authorship record. If you've pushed to a public repository, that's already out there. Note that even if you change the author, the committer is a separate record. See also the previous paragraph.

command history, or perhaps some secrets?

If there are any secrets in your .git/config, these might be leaked.

Your command history won't be directly leaked. However, it may be possible to infer your command history, at least as far as (some) git commands, via careful analysis of the contents of the .git folder. Note that this is partly true for public repositories as well, although it is much harder to impossible there to uncover anything other than commits and merges. The difference mainly comes down to your .git folder will contain artifacts from commits that have been amended, rebases, abandoned branches, and so forth.

Realistically speaking, other than maybe your .git/config, a local .git folder which is a clone of a public repository will rarely contain anything you're likely to truly consider "sensitive" unless you accidentally committed something that definitely is sensitive. In most cases, however, if you don't mind someone seeing the "official" history, you probably aren't likely to mind if they can see where/how that history has been created/edited, unless you have a near-pathological need to maintain an appearance of tidiness.

...but again, just use a bundle. The tiny amount of extra effort on your part — if any; you'd still have to pack up the .git folder contents somehow — is canceled out by how much easier it is for your recipient to use a bundle, and on top of that you won't be worried about leaking sensitive information.

Matthew
  • 423
  • 2
  • 8
  • Thank you for writing this elaborate information, this is the kind of answer I was hoping for. I'm not sure whether it would be right to accept it, since it completes the currently accepted answer, but I upvoted, and am thankful. – Paul Apr 02 '21 at 15:10
  • 5
    Another sort of inference leak might be your `.git/exclude` file. – Michael Apr 02 '21 at 17:04
7

It depends on what you were doing. E.g. there can be files that you have deleted afterwards that contain some sensitive data.

You are not the first one who asks such question. Look at the Git documentation, chapter Removing sensitive data from a repository. It describes what should you care of, what tools and what specific commands you can use to remove possible sensitive data.

mentallurg
  • 8,536
  • 4
  • 26
  • 41