Plaintext

Published 2016-04-08

I've had skippy.net for almost two decades. This site has experienced a number of transformations in that time. I've spent a lot of time looking for a visual presentation that I like. My tastes have changed over the years. I've spent a lot of time mucking around with CSS, divs and spans, and color choices.

None of those things are why I chose, way back when, to host a blog. I have a blog to share my thoughts with the world. The contents of the blog are the thing, not the way the blog looks. I'm not trying to impress anyone with the presentation of my thoughts, so why was I spending so much time fiddling with CSS?

To that end, I've completely abandoned any kind of visual styling, relying solely on plain HTML. The primary "reader" of this site is googlebot, which doesn't give a wet slap about pixel alignment, color choices, or fonts. Presumably some portion of human readers are using a feed reader of some sort, so any effort at a beautiful design are rendered moot. And for everyone else visiting this site the old fashioned way, they're not losing out on any kind of "experience".

I've been composing all of my emails in plaintext for years. Plaintext is easy to deal with. It's easy to copy and paste. It's machine readable. The same benefits hold true for this site. Why is my computer sending your computer a bunch of extra information about how to present my words? Why am I worrying about browser incompatibilities, nuances of mobile, or anything else? Your web browser, regardless of platform, knows how to render headers, images, and hyperlinks. If you want the font to be larger or smaller that's your choice, not mine.

I certainly appreciate a well crafted site. I admire those who can bend CSS to their will, and who work hard to build a beautiful experience. That's not me, though, so I'm going to focus on words again.


Second Amendment Thought Experiment

Published 2015-12-06

Some people have very strong feelings about the nature and the content of the Second Amendment to the Constitution of the United States. I do not currently have strong feelings about this amendment. I have never owned a firearm, so this right afforded to me has always been an intellectual one, rather than a practical one. As such, any modifications to the Second Amendment will have very little bearing on my day-to-day life.

A thought experiment recently occurred to me, though.

Imagine that a new constitutional amendment were to pass, either by two-thirds vote of all members of the House and Senate, or by two-thirds vote at a national convention, that substantially limited personal ownership of firearms. Would you support that amendment as the rule of law?

As a thought experiment, much is left out by design. Of course the specific nature of the changes imposed by the new amendment, and its implementation details, would effect how one feels about it. The thought experiment is not asking how you feel, but whether you would adhere to the Constitutional process and submit to the will of the people.

I can't begin to imagine how slave owners felt at the passage of the Thirteenth Amendment, knowing that one day a cultural (and commercial) institution was legal and the next day it wasn't. There's no doubt that many slave owners rejected the legality of the amendment. There were a lot of creative maneuvers executed after passage of the Thirteenth Amendment to preserve the previous status quo as much as possible, making every effort to subvert the spirit of the law.

I wonder what lessons we might learn from the Thirteenth Amendment about any potential changes to the Second Amendment.


Private Keys

Published 2015-10-11

Long time reader Bob O. sent the following (unencrypted) question to me in response to my GnuPG + mutt + OSX + GMail article:

Question on your GPG article: The paragraph on why you don't install your
private key on your mobile or home devices seems to imply that you have
better physical security on your work laptop than those devices. I realize
that this opens the article up to a discussion of how to secure your
private key, but could you add a brief overview of your choices on where to
store your private key?

This is an excellent question, and I did gloss over it in my original post.

My mobile phone is not currently encrypted, though I have thought about enabling that feature. Even if my mobile phone were fully encrypted, I'm still pretty suspicious of both Android and iOS against covert attacks from government actors. The Snowden revelations indicate that NSA, GCHQ, and potentially others have found very subtle ways to compromise a mobile phone without physical access to the device.

I could keep my private keys on a device at my house, but I'd have no real way of knowing if any of those devices were physically attacked in my absence. I realize it's unlikely that someone would break into my house for the sole purpose of accessing my GnuPG private key, but this seems like an easy precaution to take. The media on a Raspberry Pi is simply an SD card or external HDD, both of which would be easy to make copies of and then reconnect. Similarly, I don't keep my private key on my server at DigitalOcean because I have no way of knowing if the virtual machine had been cloned.

(Even absent a specific effort to obtain my GnuPG private key, the physical loss of a device containing said private key should necessitate a revocation of my public key. There's simply no good way to know if the private key was compromised or not.)

My work laptop is usually with me. It's a unibody MacBook, so it's not easy to access the hard drive directly (though I admit to ignorance as to whether there are easy ways to clone the hard drive without removing it). It also employs full disk encryption, so none of the data on the device is (easily) available to anyone who might gain access to it. OSX is not immune to malware, but it is fairly resistant to it, in general. If an actor were able to compromise my work laptop by way of specially crafted malware, there's little I could do: I don't think I'm quite paranoid enough to spot (or react to) a custom attack against me, whereas I am savvy enough to spot (most of) the general kinds of malware looking for easy marks.

So while I do think OSX may have some security advantages over my mobile phone, it's more a matter of limiting the exposure of my private key to the minimum number of devices that makes practical sense.

I do use a complex password for my private key, but if someone has access to a copy of my private key then they can attack it all day long. They can run through every permutation of every possible password until they get access. It might be time consuming, and it might be expensive, but eventually the key will be cracked.

This password for my private key is not stored in my password manager, and to the best of my knowledge not written down anywhere. By using the GPG agent I can avoid repeated entry of my private key password. This reduces, but does not eliminate, the risk of keyloggers.

There are additional things I can (and may) do to further enhance my security. I do not currently have an expiration on my GnuPG key. I should set one, and take the time to extend that expiration as needed, as long as my key hasn't been compromised. I should also generate a revocation certificate.

I don't believe that I'm the target of government (or other) surveillance, so extreme paranoia is not driving most of my decision making. Nonetheless, I'm trying to take reasonable precautions to protect my private key from easy exploitation. I do have an offline backup of my private key stored securely, in case my work laptop suffers a catastrophic failure. Hopefully I'll never need to use it.


GnuPG + mutt + OSX + GMail

Published 2015-10-10

A little over two years ago I generated a new GnuPG key. I had been using a 1024-bit key created in 2004, so I created a new 4096-bit key. I've used this new key only a handful of times since it's creation.

In early 2014 I joined Keybase with high hopes of seeing an increase in GnuPG adoption. A few folks I know use the service, and we've cross-validated one another; but none of them have sent me any encrypted messages. Of course, Keybase's larger utility is as much in "proving" my various online identities as it is in facilitating encryption.

At the 2015 Ohio LinuxFest, one of the birds-of-a-feather sessions was a keysigning party. There were about a dozen of us in attendance, some complete novices and some GnuPG experts. It was a great opportunity to meet a few new folks, as well as pick up a few GnuPG best practices.

All of this took place shortly after I declared my intention to learn mutt for my day-to-day email usage. Mutt has great support for GnuPG, and I was hopeful that this support would encourage me to use GnuPG as much as mutt.

I've learned rather a lot in the last couple of weeks, and this post is an effort to record and share some of that information for others. Aside from a few OSX specific bits, most of what follows should be generally applicable to Linux users as well.

All of what follows is my own opinion. You likely don't know me, so you should not trust my opinion. Do your own research, and figure out what settings make sense for you! If you find any factual inaccuracies in my suggestions, please contact me and let me know!

GnuPG

I've been using OSX exclusively for my day-to-day desktop computer use. (My employer has a few compliance requirements not yet easily satisfied by Linux, so this is as close as I can get to a POSIX-based system.) There are two ways to install GnuPG onto an OSX system: Homebrew or GPG Suite. I chose the latter, because it provides good Finder and Mail.app integration, but these are conveniences only.

The default options for GnuPG are okay, but not great. Depending on your level of paranoia, the defaults may be downright disastrous. One of the more interesting documents I found was Operational PGP, which was chock full of usefully paranoid suggestions. That, combined with OpenPGP Best Practices provided the bulk of my ~/.gnupg/gpg.conf settings.

In particular, ensure that you're not using old and insecure algorithms:

cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224

Also ensure that you're not leaking information unnecessarily:

no-greeting
no-comments
no-emit-version
throw-keyids

When using GPG Suite on OSX, be sure to make use of the GPG agent:

use-agent

The agent makes it much less hassle to use GnuPG. And it will come in particularly handy with mutt, too!

There was some interesting disagreement after the Ohio LinuxFest keysigning party with respect to proper next steps. Do you encrypt the signed key that you send? Do you individually sign each user ID on a public key? Do you push to keyservers? Each keysigning party may have different norms, so be sure to get answers to these questions before taking any actions! The Debian keysigning instructions may be useful as a reference for possible best practices.

GNU/Linux users are encouraged to use caff, which handles much of the tedium of signing and sending signatures to the folks at a keysigning party. Unfortunately, caff doesn't work on OSX (despite being in homebrew). Additionally, caff sends mail directly from the host on which it is invoked, which may not work for laptops connected to residential ISPs. You may need to correctly configure a relay host in order to make the most of caff.

Aside: pass

Once you have GnuPG configured, take a look at pass, a GnuPG based password management system for Linux and OSX. pass works well for individuals as well as groups. We use it at work, and it's proven extremely helpful.

mutt

Installing mutt on OSX is best accomplished with Homebrew: brew install mutt was my first attempt, and this does work well enough. But this default incantation leaves out a newer feature of mutt's GnuPG support: GPG Made Easy (GPGME). GPGME allows you to drastically simplify your mutt config file with respect to GnuPG. In order to get mutt to use GPGME, you need to manually compile it:
brew install mutt --build-from-source --with-gpgme --with-slang

With GPGME, the relevant section of my .muttrc file is this:

set pgp_autosign=no
set pgp_auto_decode=yes
set pgp_sign_as="0xD8F2E57BED0F2C0A"
set pgp_replysign=yes
set pgp_replyencrypt=yes
set pgp_timeout=1800
set pgp_use_gpg_agent=yes
set crypt_use_gpgme=yes
set crypt_replyencrypt=yes
set crypt_replysignencrypted=yes
set crypt_verify_sig=yes

I realize that looks like a lot, but compare it with the recommendations from the mutt wiki.

GMail

If you're a GMail user, you can use something like the following to get mutt to connect:

set imap_user = "skippy@skippy.net"
set imap_keepalive=60
set imap_passive=no
set imap_check_subscribed=yes
set imap_idle=yes
set mail_check=60
set smtp_url = "smtp://skippy@skippy.net@smtp.gmail.com:587/"
set from = "skippy@skippy.net"
set smtp_authenticators = 'login'
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"
set postponed ="+[Gmail]/Drafts"
set record="+[Gmail]/Sent Mail"

OSX users: take particular note of the set smtp_authenticators directive. This resolves a bug with the homebrew formula for mutt. I was unable to login without this.

I don't want to type in my GMail password every time I connect, and I don't really want to leave a plaintext copy of my GMail password in my .muttrc. Since I'm using GPG and the GPG agent, I can encrypt my password and decrypt that on the fly when mutt starts!

source "gpg -d ~/.mutt/passwords.gpg |"

For lots of other great suggestions about dealing with GMail, check out GPG / Mutt / Gmail by Ben Nagy. I particularly liked the recommendations for SSL hardening, and not blindly trusting SSL certs presented by IMAP and SMTP servers.

Conclusion

It's been a fun adventure learning some of the intricacies around GnuPG, mutt, and GMail. The fact that I'm using OSX does tend to complicate things, since so many howtos online are written for GNU/Linux users.

I still use the GMail web interface with depressing frequency, despite all the effort to configure and learn mutt. I'm trying hard to use mutt exclusively, but that's quite an uphill battle.

One of the interesting things that all of the above work does not address is shared access to my Inbox from my laptop and my mobile phone. I will not install my GnuPG private key onto my mobile phone, so any encrypted emails I may receive will need to lie unread until I can access them on my laptop. Similarly, I won't install my private key onto my VPS server, or a Raspberry Pi at home, or any other device I'm not likely to have in my immediate possession at most times.

UPDATE: I discuss private key security in a subsequent post.

So far this hasn't been an issue, given the paucity of encrypted emails I receive. If encrypted emails were to become more commonplace for me, I might need to revisit my policy against my private key on my phone, since my phone is where I read the surprising majority of my emails these days.

References


How To Answer Questions The Smart Way

Published 2015-03-01

Eric Raymond's "How To Ask Questions the Smart Way" was published in 2001, and has been very popular ever since. It gets referenced on my local Linux User Group mailing list with some frequency (usually alongside an admonishment to stop top-posting). To be sure, it contains a lot of good advice for how to perform research, how to frame a question, and what salient information is generally a minimum required to solicit help.

And yet, I absolutely despise this document. Raymond spends roughly ten thousand words telling people what is expected of them when they seek help, including how not to react like a loser, but can't be bothered to write more than four hundred words on how to answer questions in a helpful way.

In an effort to remedy this glaring oversight, I share here some guidance I've learned over the last dozen years participating in open source communities, as both a novice and an expert.

Be Compassionate

Much of Raymond's treatise is predicated upon the assumption that the people providing answers are all Very Busy People, and their time is not to be squandered.

We take time out of busy lives to answer questions, and at times we're overwhelmed with them.

I counter that the people asking for help are equally Very Busy People, and deserve to be given the same respect that you expect.

Many times, people asking for help are frustrated. They may be under a deadline. They may have inherited a problem about which they know next to nothing. Solving the problem is not what they want to do: they want to do whatever it is that the problem is preventing them from doing.

The person asking for help is already taking time out of their busy day just to ask for help. Quite often in this day and age, the most expedient solution to an open source problem is to stop using open source. Anyone who takes the time to ask a question deserves our support.

Be Supportive

Raymond's second piece of advice about providing answers is "Reply to a first offender off-line." The very verbiage of this advice makes clear that he perceives a power differential, and that people who don't ask questions in The One True Way are offenders.

Are we, as a group, more interested in enforcing a specific set of behaviors or are we more interested in fostering a culture of respect, collaboration, and participation? To view interlocutors as "offenders" ensures the former. I'm much more interested in the latter.

So if someone doesn't follow every one of Raymond's pronouncements for asking a good question (or, God forbid, top-posts!) I say "Who cares?" Be nice to them. Demonstrate that they are amongst friends. Gently and positively encourage them toward preferred behavior, but do so in a way that makes sense. There's a history to many of the cultural elements of open source, and new members won't be privy to that history. To scold, reprimand or "correct" people, off-line or on-line, is to promote a culture of negativity, and to preserve the perceived power differential.

Why not share -- openly -- the history of why cultural norms are what they are? To do any less is to say that things are the way they are by simple fiat.

An important corollary exists: be willing to accept that times have changed and the original reasons for any specific culture behavior no longer obtain.

Be Responsible

If you subscribe to a mailing list with the intent of both asking and answering questions, take some responsibility for the fact that you have made a conscious choice. Other list participants aren't coming to you personally, begging for your wisdom. They're casting their questions into the ether, eagerly awaiting an answer from anyone. If you're too busy to deal with that, then perhaps you're a member of the wrong mailing list?

Be Patient

If you're a member of a technical mailing list, you must accept that there will be a steady stream of new participants joining the list. New members will be ignorant of the list's cultural norms. They may never have heard of Eric Raymond before, and so not realize the implied significance of your link to his screed.

You should be as patient with the first new member as with the ten thousandth new member. These are people who have taken their time to participate in the forum, just as you have. In time, they too will be expected to shepherd new members, such that the burden of cultivating culture is shared and distributed.

Be Involved

Successful communication requires real effort from all parties involved. It is not acceptable to put the entire burden for successful communication onto the person who is struggling to find an answer to a problem. If you want to help, you need to accept that there is a burden to you for doing so. You'll hear the same questions again and again. You'll have to repeat your answers again and again. You'll misunderstand people. People will misunderstand you.

The end result of your efforts will be a gradual increase in the number of like-minded people willing and able to help share the burden of providing help to those who need it. And isn't that community empowerment one of the reasons we all like open source to begin with?


← Older Posts Newer Posts →

home / contact / flickr / github / keybase / linkedin / twitter

The contents of skippy are licensed under a Creative Commons Attribution 4.0 International License.