Interesting things I learned while training to be a Fairfax County Election Officer

I spent a few hours yesterday training to be a Fairfax County Election Officer. At some point in the next few weeks I will be assigned a precinct for the March 1st primary.

These are a few things I found noteworthy:

  • Voter ID Cards: if you don’t have a driver’s license,  state ID, or any of the myriad accept forms of ID,  you can get a Voter ID.
  • Cards that have an expiration date are valid for voting up to a year after that date.
  • ExpressVote-right_webThe ExpressVote machine “neither votes nor is particularly fast”.  It’s an accessible way to fill out a ballot,  for people who are unable to do it on paper.  The machine can be operated by touch-screen,  a combination of headphones and a braille keypad, or the breath input built in to some wheelchairs. The screen also has a high-contrast mode for color-blind voters. It prints out a little slip of paper. Just like the regular ballot, you have not actually voted until you feed it into the vote scanning machine, the DS200.
  • If the DS200 had legs it would look like Gonk.
  • Voters who are over 65 or disabled can vote curbside.
  • There is no trash and no souvenirs– every bit of detritus produced by the voting process gets filed away in a particular places. Spoiled ballots? There’s an envelope for that. The zip-tie that keeps the DS200 closed until just before the polls open? Envelope 7C.
  • Those zip ties have serial numbers.

Geeky bits:

  • The laptops in the precinct used for checking voters in are on a physical LAN, and share (peer-to-peer) an MS-SQL database, exported from the county registrar’s master database within the last day or so. Each laptop starts out with a complete copy of the database, on a thumb drive. It seems like this would be unnecessary if all of the laptops are networked (since a single database could propagate out to the other stations, through the same mechanism they use to keep in-sync), but it’s probably a significant speed-up, and more fault tolerant.
  • There’s no connectivity to the internet or elsewhere on on those laptops, and no other software besides the “Pollbook” app.
  • Attempting to do anything else on the laptops is probably  a felony.
  • The DS200’s are not networked at all, all votes are stored on a thumb drive. At the end of the polling day, the machine spits out a paper tape with the day’s results, along with images of any right-in votes. The Chief Election Officer uses that print out to fill out the final paperwork and report on the precinct’s results.
  • When using the DS200, you’ll see a count of votes for the current election, and a”protected count”. This second number is the total number of votes cast over the lifetime of the machine.

Explaining Reproducible Builds

Reproducible Builds is the sort of idea, that once I started to grok it, I started thinking about how I would explain it to others.

Luckily, I work in a place where, every quarter, there’s a chance to give a lightning talk, or short presentation. The audience is generally tech-savvy, but only some people are part of systems management, devops, or related disciplines where they have probably already encountered the idea. Here’s what I came up with:

What would the Manhattan Project have done with an iPhone?

A coworker, Seph Coster, tweeted:

My first instinct was to respond with a joke. Something like “#oppenheimerselfie”.

I think what Seph was imagining, is the computing power an iPhone represents. In terms of raw capability, the devices we carry around in our pockets (and even on our wrists) definitely outclass the vacuum-tube based computers of that era. It would have been transformative.

Except…

I don’t know what the rules of this single device time travel scenario are, exactly– but I don’t think they could have put an iPhone to much use. The iPhone doesn’t support freedom 0, “The freedom to run the program as you wish, for any purpose“.

Even if the Project had the interest and resources to to compile their code into a form that would run on the iPhone, the iPhone will refuse to run any software that hasn’t been “signed” by Apple and distributed via the App Store. Yes, app developers can transfer their own code onto their own devices, but only if they’ve paid their yearly $100 to Apple.

Among myriad other things, both of those paths for getting code to the device require an internet connection (which doesn’t exist yet), and place a company (which doesn’t exist yet) in control of what software can run, or who is an authorized developer.

Could they have gotten around those restrictions? Maybe. Reverse engineering modern DRM systems (or figuring out how to jailbreak), with 1950’s technology, would be big undertaking. Perhaps as big as the rest of the Manhattan Project.

I haven’t brought up one particular very sweet solution yet– if they managed to reverse-engineer WiFI or other wireless protocols, and run a web server, they could theoretically run web apps. It’s a stretch, but perhaps more plausible than routing around the restrictions above.

That aside, almost any other common computing device, any mac, any PC, or phones and tablets running Android, would be more useful.

RHEL Coda

Previously, I wrote a bit about trying out Red Hat Enterprise Linux Workstation on my laptop: RHEL Notes, RHEL Notes II. I think, ultimately, I was taken in by a pretty simple critical thinking error (I’m sure there’s a fancy name for it):

  • Thing X costs money, under most circumstances
  • I can get thing X for free
  • Therefore, I should certainly use thing X

RHEL Workstation is a perfectly nice desktop, but there’s nothing that makes it a better choice for me, than Fedora, Debian, Ubuntu, Arch, Elementary (and on and on). I want software that’s more up-to-date, doesn’t require a license key, and doesn’t include arbitrary limits on what software I can use.

For now, I’m using Fedora 22.

Docker works, docker-compose fails

I ran into a funny issue yesterday. I was attempting to resurrect an old project (made with fig) using fig’s successor project, docker-compose. For reasons that will make sense in a minute, it’s worth noting that I’m on a mac, and all of the software under discussion was installed with homebrew. Running docker on a mac, means I’m also using boot2docker.

Plain old docker works fine:

$ docker run -it debian:latest bash
Unable to find image 'debian:latest' locally
latest: Pulling from debian
39bb80489af7: Pull complete 
df2a0347c9d0: Already exists 
debian:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:a25306f3850e1bd44541976aa7b5fd0a29beabc137f65acbac34d6918807fd6e
Status: Downloaded newer image for debian:latest
root@f51234099263:/# 

docker-compose, fails hard:

$ docker-compose up
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

A certificate problem doesn’t make any sense– docker depends on the same certificate files.

Google produced a number of false leads, but I landed on a discussion thread on Github that suggested that there is something broken about OpenSSL 1.0.2.

The comment I linked to above, suggests that I can use Homebrew to switch back to OpenSSL 1.0.1.

brew switch openssl 1.0.1j_1

But,  that presumes that I had the version in question installed at some point. Homebrew doesn’t actually delete old versions until you tell it to, so you can always use ‘brew switch’ to restore a previously installed version.

How do you install an old version, though? Homebrew doesn’t make this obvious at all. To do that, you need to locate the relevant “recipe”  file in the homebrew git repository, and identify the moment in time (in the form of a commit hash) when the software  version you want was current.

Here is the file in question. It seems like the right commit to use is ‘b5cffc8d5fc41540a41ed4deba23afbb6431435e’.

Now what? You have to roll your entire homebrew install down to that commit. In my case, homebrew was installed in /usr/local/homebrew.

$ cd /usr/local/homebrew/
$ git checkout b5cffc8d5fc41540a41ed4deba23afbb6431435e
Note: checking out 'b5cffc8d5fc41540a41ed4deba23afbb6431435e'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at b5cffc8... openssl: update 1.0.1l bottle.

Then, you can ‘brew install openssl’, and you’ll get the correct version. After that, docker-compose will work.

$ docker-compose up
Creating solr_1...
Building solr...
...