Git Signed Commits in Windows and WSL

Developing on Windows 10 has been a joy since the release of Windows Subsystem for Linux (WSL), however straddling the line between Windows and Linux can sometimes cause friction.

With the steps outlined below we can resolve the No secret key error that can sometimes pop up while signing commits from Windows while also having GPG setup with a passphrase (which would be silly not to have, right??) in WSL.

My setup is as follows:

  • Windows 10
  • WSL v1
  • Git 2.28
  • GPG 2.2.21 with a key that has a passphrase
  • IntelliJ IDEA (but this probably applies to other Windows IDEs)

The Error

When I’m working from my WSL console, I can easily create signed commits. My keys are stored in ~/.gnupg and everything works a treat. However, when I try to create a signed commit from IntelliJ in Windows, I get the following message:

Commit failed with error
	gpg: signing failed: No secret key
	gpg: signing failed: No secret key
	gpg failed to sign the data
	failed to write commit object

When performing the same commit via the WSL console, I would get a passphrase prompt, and the commit would succeed if I enter the correct passphrase:

I didn’t get a similar prompt in IntelliJ, so it became clear that I needed a Windows option for entering my passphrase. I already had gpg installed for Windows, but it was command line driven and I suspect there’s not a straightforward way to communicate to IntelliJ that a passphrase is required. I also didn’t want to wrap gpg and store my passphrase in cleartext (because that’s like a security mullet – vault door in the front; screen door in the back).

The Fix

The quickest, most secure, way to get this working would be to install Gpg4win and import my gpg keys from WSL. So, to do this, the first task is to export my keys so they can be imported. From WSL I just drop them on my desktop:

gpg -a --export-secret-keys > /c/Users/emerle/Desktop/gpgkeys.asc

Once this is done, you can import these into the Kleopatra application that comes with Gpg4win. Be sure to permanently delete that gpgkeys.asc file – it has your private key(s) in it! Once you finish the import into Kleopatra, you’ll have something like this (but less blurry)

Now, the only thing left to do is tell git to use Gpg4win. From the Windows version of git, you set the gpg.program

git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe"

Now when IntelliJ uses the Windows version git to perform the commit, it will use the defined gpg.program. In this case, we should see our passphrase prompt when we try to commit:

Because you added this setting to your Windows git configuration, this shouldn’t interfere with your WSL configuration. Now you can seamlessly commit from either Windows or WSL with a GPG signature!

Happy developing!

Evolution

There’s this widely accepted theory in science called Evolution (and, no, a scientific theory is not the same as your uncle’s “theory” that chipmunks are stealing his WiFi). The high-level idea behind this scientific theory is that every organism undergoes random mutations. Some of these mutations may be beneficial, detrimental, or immaterial to the survival of the organism. When a mutation is beneficial such that it gives the organism an advantage over others for a shared set of resources, that organism tends to thrive.

We can take this concept of evolution and apply it to software engineering (though on much smaller time scales). To do so, we start with the smallest unit of work that provides tangible value. The Marketing and Product folks like to call this the Minimum Viable Product or Minimum Viable Experience. For the sake of the analogy, we can call this Generation Zero (G0). This is our single-celled organism that’s not capable of much, but it still constitutes “life”.

For G0 to be useful, it must be able to interact with the outside world. See, much like in the classic Evolutionary Theory, we need feedback. Our feedback won’t be life-or-death (although many ideas have died in the zeroth generation); it will be in the form of user feedback. How well did G0 meet our goals? What are the friction points? Are users getting confused and not following our calls to action? We can collect all of these metrics through innumerable mechanisms; the important idea, however, is that we delivered something and we’re gathering feedback.

Armed with this feedback we can now start to imagine what Generation One (G1) is going to look like. We build upon some of the simple ideas required for G0 and extend them in directions that we feel will make the product or service better. This may mean adding extra features or widgets, or creating a basic version of your service as an iOS and/or Android application, or tightening up your deployment strategy, or scaling out in the cloud, or whatever will bring more business value. After all, business value is the one true goal (it’s worth noting the value may not be monetary!).

Great! We now have G1 (our multicellular oganism) and it’s been deployed and we’re collecting feedback. If there were any UI/UX changes, you may get some very loud negative feedback like Snapchat, Twitter, Netflix, Google, Spotify, etc. But feedback, positive or negative, is like gold. This is the equivalent of fitness testing, or “survival of the fittest”; you are seeing whether the “random” mutations were beneficial, detrimental or immaterial.

As you continue through further iterations, you will begin to shape your product or service. Your single-celled organism will evolve, growing more complex with each iteration. As your product or service asymptotically approaches completion, you’ll try new things (mutations) and push them out for feedback (fitness testing) . You will continue to hone the parts that work, and discard the parts that don’t. Eventually, you will end up in one of two places:

  1. You’re at the top of the food chain
  2. You’re eaten by an organism higher on the food chain

Regardless of outcome, in order to fail or succeed, you must first “do”. This sounds vaguely like something Yoda would say, but analysis paralysis is real and can cause you to stand in one place and never make any tangible progress. Get your ideas out into the wild, get feedback, iterate and improve. You may get eaten along the way, but you also may end up at the top of the food chain. Either way, you’ve gained something that nobody can take away from you: experience.

Credits

Evolution logo: Johanna Pung / CC BY-SA

Show Me The Code

The Proof Is in the Pudding

I’ve always hated that expression.  What does that even mean?  The proof of what is in my pudding?  The original expression was more along the lines of “the proof of the pudding is in the tasting/eating”. Idiomatically, we all understand the abbreviated version to mean, “I’ll believe it when I see it” or in general, that the value, effectiveness and even existence of something cannot be validated until it is tested. 

Show Me the Code

In software engineering we have a similar, albeit less abstract, expression: “show me the code”.  I’m sure there are similar expressions in other professions.  I know there was an expression in the movie Goodfellas that was similar in its unapologetic tone (I’ll leave identifying this expression as an exercise for the reader – it’s a great movie anyway). In the software world, however, what we’re trying to express is that an idea, diagram, proof-of-concept, and basically anything that is not actual production code is, well, “worthless”.

Okay, I was being hyperbolic with “worthless”.  There is a ton of value in all the things that I mentioned, but that value doesn’t materialize into business value until those things are expressed as functioning production code. 

Talk is cheap. Show me the code.

Linus Torvalds

Do you have a brilliant idea?  Great; show me the code.  Do you have an academic paper extolling the virtues of some process? Great; show me the code.  Have you put together an architectural diagram?  Great; show me the code.

The 90/90 Rule

The 90/90 rule, is a humorous observation attributed to Tom Cargill of Bell Labs in the 1980s:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

 Tom Cargill, Bell Labs

What I’ve seen time and time again is the most talented engineers are hyper-engaged and focused early in a project, for the “fun stuff”.  This might include playing with a new language, library, or platform.  It might mean spinning up cloud resources and building out a cluster.  It may mean tearing open some hardware and reverse-engineering it.  It may mean working some magic to performance tune some questionable part of the system. In short, it’s stuff that’s new and novel.

You see, engineers get bored easily.  We don’t want to spend time doing the same thing over and over; we need shiny new toys to excite the neurons in our brains.  Because of this, our excitement tends to wane as projects progress.  What was new and exciting becomes boring and stale.

Once the novelty wears off, engineers get an itch to move on to the next shiny new toy.  They don’t want to be tied to some project that’s entering the dreaded “maintenance mode”.  They don’t want to be answering user questions or writing documentation or convincing management that component XYZ needs to be refactored, so development starts to slow as engineers divert their energy to more exciting projects.

Show Me The (Finished) Code

With software, nothing is ever truly done, we just asymptotically approach zero features and defects.  But there is a version of done where we’ve met our business requirements and provided peak business value.  This is just before we reach the zone of diminishing returns.

An image showing the relationship between work, time and business value.
Fig 1 – The relationship between outstanding “work” and business value over time

This is probably best illustrated by the expertly drawn diagram above (Fig 1).  As the amount of “work” to be done (features to be implemented/outstanding defects) decreases, business value (ideally) increases. Eventually, over time, we stop producing additional business value and enter a phase of diminishing returns.  This is oversimplified, but what it is meant to illustrate is that we produce the most business value toward the end when most features are implemented and most defects are resolved.

So, our expression, “show me the code” is imprecise.  Not only do you need to “show me the code” as it is now, you need to show me the plan for how to get to “done”, your plan to get it into production, and your commitment to producing peak business value.  I’m not suggesting that we adopt a new expression with this level of verbosity, we just need to collectively make sure that we agree at what “show me the code” is trying to elicit.

Toward Building Value

Our jobs as engineers is to provide value to the businesses that employ us. We are biological machines that are tuned to take complex, abstract, problems and turn them into delivered products and services. The key word being “delivered”.

While there is value in ideas, proofs-of-concept, research, and experimentation, the “proof of the pudding” is in deploying your software to production and then diligently supporting that software until such a time that your time is better spent elsewhere.