Nullniverse 1.0, 10-03-2022: Git

This guide is just a collection of steps and use case for implementing multi-account authentication on Github


There was a time when cryptic sysadmins and developers integrated their scripts and codes underneath a pile of skull and rocks (kindly called Revision Control Systems).

Times passed, and after the plume of dust and smoke succeeding the meteor impact dissipated, new systems came to fruition aiming to save the last remnants of living dinossaurs who dared to still keep facing an screen and handling a keyboard - sometimes even using a mouse! - non-stop.

Evolved offsprings filled the earth, and rapidly became popular and known by their own names, like Subversion and TurtoiseSVN, the later its GUI implementation. Things were gaining traction back then, and the fast-paced rhythm on which software was being developed, spawned a new set of demon capable of spread havoc and anxiety for generations to come. Well known as Git.

Loved and hated, different tastes contributed evenly to what’s better abstracted today as source-control management (SCM) creating a rich and diverse ecosystem of tools for the occultist craft of software engineering.

In my life, I’ve only used two systems for source-control management, SVN and Git, so I wanted to give it the propper attention it deserves (Github in this case) because I’ve seen many organizations using it over the years, and people scratching their heads to be more productive while trying to avoid IT Security directives for a safer environment.

Disclaimer: I’m not trying to delve into this subject as there are a lot of useful resources and also an de facto industry standard book written about what git is and how to better leverage its system’s functionality. If you want to go deep, just give it a try!

My main concern that prompted me to write this post is because there’s so much information out there about starting point git configurations, and a lot is missed even for large orgs when they try to implement base guidelines for starters.

My goal is simple, and centered on two milestones :

  • Signing commits

  • Using multiple accounts for the same username OR getting fame & glory

Signing Commits

Signing posts is the most overlooked component when you are working for a closed doors org if they enforce self-domain usage for contributors in private repos, that is: only users with email are able to contribute on private repositories and no outside collaborators are allowed.

That works - in parts! Let’s suppose you have started small and gaining traction month by month, either in revenue and corporate growth, but also in collaborators among your team who constantly push changes to production. Once you start adding complexity in your environment, and aren’t able to assess broad aspects of individual skill sets of your team members beyond the limit scope of your product needs and engineering interactions - neither are inclined to spend large bucks with security software for everyone’s laptops - so a couple of questions arise:

  1. Are my devs skilled enough in security practices while using their machines for off-work related issues?

  2. How can I be assured that the startling new shiny tools integrated in our pipelines, doesn’t pose a security risk for the entire supply-chain of our product?

  3. What if a disgruntled employee starts to pose a security risk and plans to act on behalf of other employees to compromise our chain and our users?

  4. More what ifs…​

With these concerns at bay, a preliminary solution is to activate signed commits.

As this post from the old is explaining, it poses a question of authenticity and integrity, because:

  1. the software [in question] is critical to some type of security, an attacker might compromise you by substituting broken software for the software you think you’re getting, e.g. something with a backdoor you couldn’t easily identify. After all, you want some code, you click "download", and you trust that what arrives over the wire is what was written on the button.

Sufficient to say, it also puts another layer of trust in commits inside your org, validating contributions from its members.

So, how do you do that?

I’ll summarize the main steps below, but feel free to check this doc from Github and follow at your own pace.

  1. Install your GPG suite of tools.

    1. Windows: Gpg4win

    2. MacOS: GPG Suite integrates automagically in the MacOs keychain. Check be above documentation for nitty-gritty details.

    3. Unix/Linux: Chances are you already have it, but give gpg-agent a try

  2. Verify your main address

  3. Activate commit auto-sign after each commit, this will save time on each commit, instead of using git commit -S -m "comment" you can use only git commit -m "comment". Save you some working memory allocation.

    $ git config commit.gpgsign true
  4. Generate your key:

    $ gpg --full-generate-key

    It must be at least 4096 bits (default option) Your email must be the main email address of your Github account

  5. List and export your newly created GPG key

    $ gpg --list-secret-keys --keyid-format=long

    Copy the 3AA5C34371567BD2 part to be used in the next command.

    $ gpg --list-secret-keys --keyid-format=long
    sec   4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
    uid                          Hubot
    ssb   4096R/42B317FD4BA89E7A 2016-03-10

    Now, run the below command and copy the exhibited key in your GPG settings on Github:

    $ gpg --armor --export 3AA5C34371567BD2
    # Prints the GPG key ID, in ASCII armor format
  6. Telling Github you’re a winner. Inserting your keys in the config

    $ git config user.signingkey 3AA5C34371567BD2

The process above can be used to generate as many keys as you want. It’s useful if you plan to manage more than a single account on your machine/session, as we’ll cover in the next part.

From now on, you’re able to effectively prove yourself and sign every commit you make. Welcome to surveillance capitalism!

Using multiple accounts on git and Github

Possible interactions with git and Github in a single machine/account

account scheme

Chances are you’ve already lost at least 5 seconds of your life starring at the above diagram. I really appreciated your taste!

So, when using git on an account in a computer, you could have a virtually unlimited number of git accounts configured if you observe some tricks. But often, the most sought after feature is to maximize productivity, allowing you to commit to your professional projects, and your personal or open-source ones (thanks if you do the later).

The steps below will either work if your needs are the former, or if you want to apply a different kind of use to your accounts. Keep reading.

What the image above says, is that in some cases, you want to use your personal username to work for your org, but using the org. domain email, while trying to preserve this username and your personal email adress for your projects, also. But…​ is that possible? Yes, my defossilized sapiens!

Let’s do that now:

  1. Head back to your email settings. In this case, let’s create the scenario where you’re using your personal account and planning to use this account’s username to commit to your org.

  2. Simply add your org’s email address and then make it valid.

  3. Your primary address can be either your org or your personal one

After confirming your address, let’s go to your .gitconfig settings in your machine.

In this step, you’ll not need to configure your SSH keys for each account, as the username will not change. For possible iterations of the contrary, you could check this ancient scroll.

We are going to generate and use two additional files for this case, despite the .gitconfig file, and also will specify an static working path dir, to be used with one of the accounts (my personal taste favors the use for the professional account).

  • ~/.git-personal.conf

  • ~/.git-professional.conf

In the .gitconfig file you’ll have your path choice set and additional commands:

  • .gitconfig

        path = ~/.git-personal.conf
[includeIf "gitdir:~/Documents/YourOrgFolder/"]
        path = ~/.git-professional.conf
        defaultBranch = main
  • .git-personal

        signingkey = 3AA5C34371567BD2
        email =
        name = your-username
        mergeTool = vimDiff
        gpgsign = true
  • .git-professional

        signingkey = FD668DAFE840A89C
        email =
        name = same-username-as-your-personal-one
        mergeTool = vimDiff
        gpgsign = true

One thing to notice in the above configuration is that you can use more than one signing key, or use the same to signed-commit in both projects - make sure your boss don’t work two part-time jobs, if you’ll just one key btw.

If you’re taking advantage of this pandemic and working more than one all-remote job, you could negotiate to use your same username and enjoy a multi-org config. Just create more .git-professional# files and more [includeIf] entries.

That’s it.

I hope it has been informative to you, and I would like to thank you for reading!