Git commit config and credential confusion causes consternation for customers

Thousands of Git users are guilty of a giant security blunder. They inadvertently and unwittingly publish their login credentials for services like GitHub, GitLab and BitBucket up to their own public repositories.

If you know how Git and GitHub work, this mixup comes as no surprise. Let’s explore how it happens and how to fix it.

How Git works

Before you issue your first commit in Git, you must provide the tool your name and email address.

This information is stored as part of every commit. If anyone wants to know who updated the codebase, or email that person about their changes, the name and email address is right there at the reviewer’s disposal.

Git doesn’t validate the username you provide, and doesn’t verify the email address you submit. As long as these fields are populated with non-null text strings, Git commits proceed with this metadata attached.

Credential confusion

Now here’s the problem.

When anyone is presented with a form with two fields, the first instinct is to provide your username and password, but that is not what Git asks for.

Users who set up Git for the first time also likely will set up a GitHub connection as well, and have their GitHub credentials at the ready. Instead of providing a username and email address, users unwittingly type in their GitHub login name and password.

Somewhere between 50,000 and 100,000 users have made this mistake, according to researchers in the UK.

To ensure you have not accidentally saved a GitHub credential as part of your Git username and email address, issue the git config –list command. This shows all of the meta-data that has been set at the various Git scopes.

git list all settings command

Check your git config settings to ensure you have not exposed any private data or security credentials.

Deletion difficulty

To compound the problem, once a developer pushes a commit to GitHub or GitLab, that Git commit metadata becomes a permanent part of the public repository’s history.

Git is a fully distributed version control system, and every user that makes a deep clone gets a full history of every commit. Even if a developer fixes the credentials locally and on the remote server, the change won’t carry over to the local machines of users who previously cloned the repo.

Git credentials leak fix

If you inadvertently set your GitHub credentials as your Git username and email, and you haven’t pushed your commits to a remote repository, simply delete your unwanted commits with a Git rebase and squash, update Git with your proper username and email address, and move forward with development.

If you’ve pushed your commits to a remote Git repository, especially one that has been cloned by other users, there really is no other option than to change your account’s password and regenerate a GitHub authorization token. The distributed nature of git push, pull and fetch operations makes chasing down replicated commits across a multitude of machines untenable.

Be careful when you perform that first Git commit against a new repository. When your local Git installation asks for a username and email, don’t inadvertently provide the credentials used to access your remote repository. It’s an easy mistake to make, but it puts the security of your organization’s codebase at risk.