Scott ended up configuring GPG signing with a YubiKey, which looked like an intimidating process. I wanted to do something more basic and see if using the stock on-box storage was as straightforward as configuring SSH authentication for GitHub.
In my normal development flow, I use the git command line, either under WSL on Windows or natively on Linux. While I may use a GUI tool occasionally to help visualize the commit graph for a repository, I tend to do all of the activities that I’m interested in signing outside of them. I prefer a dedicated stand-alone command line window to embedded instances, such as the terminal in Visual Studio Code.
As a result, the process that I’m describing here is focused on integrating GPG signing into a git workflow from a stand-alone terminal window. Some things may or may not work elsewhere but, I’ve honestly not spent any time exploring or verifying other tools. The other goal that I had was to try and minimize the number of times in a day that I’d have to unlock my GPG key with a password.
GitHub has some great documentation on the process, walking through the steps needed locally as well as within the GitHub site in order to enable signing. For the most part, I’ll be referring back to them where possible, up through configuring the basic signing mechanism. There are a few things needed to enable local caching of your GPG credentials to avoid a password prompt for each commit that those guides didn’t cover.
Before starting, I find it helpful to have the necessary packages installed and ready to go, rather than pulling them down as needed. To that end, I’d recommend installing the following on a Debian-based distribution, such as Ubuntu:
build-essentialapt-transport-httpssoftware-properties-commonca-certificatescurlgitgpggnupggpg-agentpinentry-cursesI’d recommend following the GitHub Help guide - Generating a new GPG key. It has a nice step-by-step flow for each operating system. In my case, the Linux steps went smoothly and I’d echo the GitHub advice of using a 4096 bit key. As the guide mentions, you can verify the key that you created using:
gpg --list-secret-keys --keyid-format LONG
Here, again, GitHub Help provides an excellent guide - Adding a new GPG key to your GitHub account, which builds upon the previous guide for key generation. Before starting the configuration guide, you’ll want to make sure that you have your key available.
To do so, start by listing your available GPG keys, using:
gpg --list-secret-keys --keyid-format LONG
From the list, copy the id of the key that you’ll be using to sign, which will be in a line that looks like:
sec [Key Length]/[Key ID] [Date Created and Expiry Date]
If the sec line of your output is the following, then your key Id is 3AA5C34371567BD2.
sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
Once you have the key, you’ll need to export the full key in armor format. You can do so using:
gpg --armor --export << YOUR KEY ID >>
GitHub will expect the public portion of your key, starting with -----BEGIN PGP PUBLIC KEY BLOCK----- up through -----END PGP PUBLIC KEY BLOCK-----, including those markers copied as part of your key.
Once you follow the steps in the guide, GitHub will have your key registered and is ready to verify your signed activities.
The most important step in configuring the terminal is to tell git to make use of your key. Again, GitHub Help has a useful guide - Telling Git about your signing key, from which the steps that we’re interested in fall under the Telling Git about your GPG key title. In a nutshell, the steps are:
.gitconfig to associate the key by using the command:git config --global user.signingkey << YOUR KEY ID >>Optionally, if you’d like to instruct git to always sign commits and tags, you can run the following to update your git configuration:
git config --global commit.gpgsign truegit config --global tag.gpgsign trueAt this point, you’re able to perform end-to-end signing for commits, tags, and related GitHub activities. The unfortunate part is that your git client will prompt for a password before each of those operations, which tends to have a negative impact on productivity. To get around this, it is possible to cache your GPG key password, allowing you to use the git client normally, without additional entry, but producing signed commits.
Unfortunately, this is an area where there wasn’t a helpful GitHub guide and most of the resources that I found were focused on macOS and/or out of date. The basic gist of what we’d like to do is use the gpg-agent as a cache for the credentials and integrate that with the WSL terminal, having the curses user experience prompt for entry of the GPG password, so that it’s very clear when it’s needed.
To start, we’ll need to configure GPG to make use of the agent for caching and set the key used by default. In ~/.gnupg/gpg.conf, add or update the following:
# Uncomment within config (or add this line)
# This tells gpg to use the gpg-agent
use-agent
# Set the default key
default-key << YOUR KEY ID >>
The next step is to configure the GPG Agent to cache your password and instruct it how we would like to be prompted for password entry. The GPG Agent allows for the time of the cache to be specified, so that you’re able to make the choice that is right for you. In the example, caching is set to 400 days (34560000 seconds) so that it can be entered once and then is not needed again until the computer or WSL session are restarted. In ~/.gnupg/gpg-agent.conf, the cache times and an executable for password prompting are registered. The GPU configuration should contain the following, though you may need to change the location of your pin entry program to the output of the command which pinentry-curses, depending on your operating system:
default-cache-ttl 34560000
max-cache-ttl 34560000
pinentry-program /usr/bin/pinentry-curses
The final step is to ensure that the GPG agent launches when your WSL session starts and that the environment is prepared. Note that this is an area where things have changed fairly recently, and most of the resources that I found on the web were outdated. The approach that I’m using here was tested with GPG v2.2.4 and GPG Agent v2.2.4. In either ~/.profile or ~/.bashrc, add the following:
# enable GPG signing
export GPG_TTY=$(tty)
if [ ! -f ~/.gnupg/S.gpg-agent ]; then
eval $( gpg-agent --daemon --options ~/.gnupg/gpg-agent.conf )
fi
export GPG_AGENT_INFO=${HOME}/.gnupg/S.gpg-agent:0:1
If you’ve gotten this far, then git in your Windows Subsystem for Linux terminal should be all set to sign commits. While there may be a few steps involved, they felt reasonably straightforward to me, once I had figured out the environment configuration. Hopefully, this guide helped to lay out the end-to-end steps and will save others from having to piece them together from multiple resources.
December of 2018 marked the 20th anniversary for my being given money to tell computers what to do. As I’m currently in the process of adjusting to a new role, I thought that it may be amusing to reminisce back on the first paying job as a developer that I had.
One of my big goals going through college was to graduate without having any loans or other debts hanging over my head. As someone paying my own way, that meant that I didn’t have the luxury of exploring unpaid internships nor taking a low paying position to gain experience. Luckily, the fast food job that I started in high school had a tuition reimbursement program for college students. Unfortunately, that means that I had been working in the food service industry for roughly 8 years by the time I entered my last semester. As you can imagine, I was ready for a change and chomping at the bit to move into my chosen field and start building my career. By the mid-point of my last year, my tuition was fully paid and I excitedly began looking.
Given that I live in an area well outside of any urban center, my choices for a programming position were somewhat limited since I had to be close enough to make the drive to school for classes. Remarkably, though I had tough luck searching, I somehow caught the attention of a local(ish) company who reached out about a role.
The interview process was a bit odd and awkward. I wasn’t asked any technical questions nor, really, anything beyond whether I’d be willing to learn FoxPro and what I expected as a salary. They weren’t forthcoming with much about the company or product and came across as overly secretive. I negotiated up from the $8 an hour that I was offered to a whopping $10 an hour. It was a slight pay cut from what I was making, but I was finally going to stop smelling like grease and spend my day writing code!
The company was small and split its efforts between doing custom installation of networks and developing a software package aimed at a niche market of managing a small business in a very specific industry (details intentionally vague to avoid calling out the company).
The management software, like most packages in the late 90s, was distributed on physical disks and accompanied by a very large manual. A new version was created each year which customers could opt to upgrade to or not. Support contracts and live call center access was sold as a separate add-on. It was written in Visual FoxPro and shipped as a core unit with some optional add-ons. The FoxPro runtime was packaged and each of the core and add-on modules were included as loose FoxPro files in the directory. All-told, there was one directory level that contained a hundred or so FoxPro files of different types and then the files and structure for the FoxPro engine.
The software didn’t change very much from year-to-year, typically. A few bug fixes, some minor enhancements, and maybe a retired feature were typical for a yearly ship cycle. The big change was an update to the bitmap that served as the background for the application and loading splash screen. It always had the year featured prominently as part of the product name. (To be fair, this was back in the days of Windows 95, Windows 98, Office 95, and similar naming schemes.) Apparently, customers were willing to pay a solid 8-10 thousand dollars each year for an upgrade so long as the splash screen had a new year displayed and a new, thick manual came with the box.
The owner of the company, Mike, was the person that “interviewed” me. He and a partner had started the company and wrote the original few years of the management software before Mike stepped away from hands-on development and hired others to do the work. By the time I joined, Mike had been away from programming for a solid 10+ years, but his shadow loomed large. I learned very quickly during my first few weeks that Mike still dictated many of the practices for development and that my initial impression of him being a bit odd was on point. He had some interesting rules that we had to follow:
I suspect that there were more quirks, but those are the ones that I can still recall. My final memory is that, after arguing that using an array was necessary to implement whatever first task I was assigned, I was banished to being a networking cable pull assistant for the next two weeks as “a time to reflect on the importance of following standards.”
Shortly into my tenure, one of my college professors approached me with an opportunity that he had been kind enough to recommend me for. I was offered double what I was making to take a role working on technology that wasn’t in danger of being obsolete, Visual Basic - quite a hot technology at the time.
Thus ended my time with Mike’s company. It may have only been 3 months, but it left quite an impression.
]]>The fix appears to have already made in the next branch in the Truffle repository, but I was able to hack my way around them for the time being. If you’re running into the same issue, you may be able to work around it until the next Truffle package release by replacing $NPM_ROOT/node_modules/truffle/build/Assert.sol with the version in this Gist.
geth as both the server and a miner node for a private network. I created the network using geth --datadir=./chaindata/ init ./genesis.json. After launching the console in another window using geth attach, each time that I tried to invoke miner.start(), I was met with an error because miner was unknown. Unfortunately, I didn’t find much help in searching the web - there seemed to be few, if any, mentions of it.
It turns out that the default set of APIs that geth published did not include miner, nor did it include admin which is often referenced by tutiorials for managing the network. The good news is that these are easily configured using the --rpcapi parameter; launching the network using geth --datadir=./chaindata/ --rpc --rpcapi "eth,net,web3,admin,personal,miner" fixed my issue.
Theory based on member data working correctly.
I wasn’t able to turn much up in a few searches, so I wanted to capture it here, lest I forget again in the future. The basic structure that worked for me was:
namespace MachineLearningBook.SpamDetector.UnitTests
module DocumentTests =
open FSharp.Reflection
open MachineLearningBook.SpamDetector
open Xunit
open FsUnit.Xunit
type ``Parsing a DocType should produce the expected results`` () =
static member DocTypeNameData
with get() =
FSharpType.GetUnionCases typeof<Document.DocType>
|> Seq.map (fun case -> [| case.Name |])
[<Theory>]
[<MemberData("DocTypeNameData")>]
member verify.``Exact DocTypes can be parsed`` (docTypeName:string) =
let result = Document.DocType.parse docTypeName
result.IsSome |> should be True
result.Value.ToString() |> should equal docTypeName
Hopefully, that helps someone (or future me) to avoid some pain.
]]>To fix discovery, here’s the steps that have helped get me working again:
CompnentModelCache directory from the application data for the current version of Visual Studio. For example, for Visual Studio 2017 v15.5.6, I need to delete: %LocalAppData%\Microsoft\VisualStudio\15.0_7464e363\CompnentModelCache%temp%\VisualStudioTestExplorerExtensionsThough it was written in reference to Visual Studio 2013, this StackOverflow Thread was incredibly helpful and still relevant to Visual Studio 2017. It’s where I found the right combination to fix my issue after some trial-and-error. If the above isn’t working for you, there’s some other advice in the thread that may.
]]>After doing a bunch of searches, and trying a variety of things that didn’t work, turns out that the root cause had nothing to do with the solution or its projects. Rather, it was related to my PATH environment variables. In my case, the system PATH contained a path segment that was wrapped in double quotes and wasn’t playing nice. Removing the quotes fixed things up and hasn’t seemed to have a negative impact in other areas that the PATH is used - at least, not that I’ve noticed so far.
I’m not sure if the underlying incompatibility was related to Visual Studio or the xUnit test runner, but thanks to this xUnit issue for shedding light on the problem.
]]>