Thought I’d do a little thread on the basics of #git and some #infosec tidbits:

Very quickly - git is the most popular tool used to manage source code, and while used by services like GitHub it is a seperate thing

Some quick terms:

Repository - this is where all your code is stored, as well as a .git folder that keeps track of your history and other essential bits of info.

Commit - a snapshot in time of your files, referenced by the SHA1 hash of the state of the repository when someone chose to commit those files.

Branch - a split in the timeline, you can branch off a particular commit and continue adding to it without changing other branches.

Pull request - this is something specific to remote hosting of git repos, once someone has made a branch they can ask to merge it into the main (or another) branch.

Now for the fun tidbits:

- Commits have an author, which has details like email address and name, this can be set to anything and is not verified in any way. For example, I can create a malicious commit pretending to be someone trusted and push it to a remote, and it will be (nearly) indistinguishable from a commit by them. In order to mitigate this, sign your commits with a GPG key!

- Websites with accidentally published .git folders - these are super juicy, while the current state of the repository may not have any credentials or leaked, a .git folder contains all the history of the project, people often leak an API key once and remove it in the next commit. It’s still there in the history.

Let me know if I’ve missed any fun bits!

Follow

@jett To pair with the "leaked .git may contain credentials" tip, when you want to remove a file completely from your repo due to it containing credentials, you can do:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

from git-scm.com/docs/git-filter-br

@kemuri this goes against the age old advice of delete the repo and start again ;p

(Very useful command)

@kemuri @jett

You’ll also need to run `git gc --prune=now`. Dangling objects can hang around indefinitely, depending on GC automation on both the local and the remote.

@kemuri @jett I think if you really want to make sure there's nothing still in .git you also need to run git gc --prune=all after running git filter-branch. This also has the obvious effect that if you screwed up the filter-branch command there won't be any way to recover what you had in the repo before, so it may be better to run this in a fresh clone.

@vegard @kemuri @jett A simple way to reduce the risk of accidentally publishing the .git is to separate the repo and the worktree, keeping the former somewhere inaccessible to the web server.

Sign in to participate in the conversation
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.