Mutt account passwords

First, to give credit where it’s due, I started here. That said, here’s how I store and access account passwords in mutt on Linux.

## -- Passwords: encrypted by gpg --------------------------------------------------------------

source “/bin/gpg -d ~/.keychain/mutt.password.neopost.gpg 2>/dev/null |”

The source line in gpg tells mutt to decrypt a file at startup. The file .keychain/mutt… contains two mutt configuration lines:

set imap_pass = "<my_email_password>"
set smtp_pass = "<my_email_password>"

I created it as follows:

$ cat <<EOF | gpg -r <my_gpg_id> ~/.keychain/mutt.password.neopost.gpg
set imap_pass = "<my_email_password>"
set smtp_pass = "<my_email_password>"

Gpg knows how to decrypt this file and retrieve the plain text configuration. Note well that I used a “Here” document to create the file. This keeps mail password out of the filesystem. Simple stuff, at mutt startup the first time I use it, gpg-agent asks for my gpg key and unlocks the configuration snippet.

Of IPv6, and unhappy eyeballs

I’m a dinosaur. I still bring a little Soekris Net5501 configured as a NAT gateway with IPsec back home when on vacation. This solution works best in hotels that still offer Wired internet. I do this because:

  • Majorly, In many cases a hotel’s WiFi is a great example of the worst case engineering solution with wifi tuned just well enough that web browsing doesn’t suck but nothing else is considered.
  • Minorly, Hotel’s in the United States will probably be the last places on Earth to get IPv6.

The other advantages should be obvious. By bringing a router I can control or at least police my DNS.

My Soekris is tiny. It takes up about as much space as three tee shirts in my packed bag including an Ancient Apple Airport Express that can be tuned to run on 5GHz only. Off hand I want to mention that configuring 5GHz WiFi in each hotel room might bring the best improvement to WiFi overall but hoteliers can’t do this because lots of people have old devices that don’t do 5GHz or don’t do it well. No one wants to be the guy trying to explain to a customer that the problem isn’t the WiFi, it’s the customer’s 2007 vintage MacBook Pro that can’t use channel 149.

So, note my surprise when I find that things aren’t working better on my custom wifi, homed to the edge router over ethernet, during my latest hotel stay. What happened? I think this…

My router connects the internet and establishes a tuned IPSec tunnel back home. Once that works, it advertises IPv6 addresses from my /48 which route back to my house and then out to the internet. If the latency for all of that is 10ms no one would notice the difference. If it goes greater than 30ms things start getting funky. We’ve crossed into a time where if you have a dual stack machine, one with both IPv4 and IPv6, you’ll try to use IPv6 for outbound work first and revert to IPv4 only when v6 has too much latency. Well, folks, when you have just enough latency, this doesn’t look pretty.

No solution yet and possibly not ever. The problem with latency issues like this is that you can’t easily fix them. That’s why tuning latency out is so important. I’ll post more when I know more.

Emacs use tabs rather than spaces.

Today, about the only place you should see an ascii TAB in a file is in a Makefile. In a world where memory is metered as gigabytes of RAM and terabytes of storage on fast SSDs there is absolutely no need to save space in a source code or configuration file by using a tab rather than two or four or eight spaces. Note well that I may be talking to your editor configuration and not you. But when you write code you should say what you mean and mean what you say unequivocally. I say this because I have been looking at a whitespace difference in my puppet checks for better than a month now. This is because my file has in production has tabs and my file in the puppet/git repository has spaces.

To that end, I’m linking this bit of Emacs magic for readers and my future self.

Submission brutes

Brush aside vandals attacking my submission daemon with a little sed:

submission_brutes=$(bzcat /var/log/maillog.0.bz2 | \
cat - /var/log/maillog | \
sed -Ene '/postfix\/submission\/smtpd.*errors after AUTH/s/^.*[^0-9]+(([0-9]+\.){3}[0-9]*).*$/\1/p' | sort -u)
[[ ! -z "${submission_brutes}" ]] && pfctl -t blackhole -T add ${submission_brutes}

pf required: pass proto ipv6-frag all

FreeBSD’s pf has serious problems with ipv6 fragment handling. The problems cascade into other issues like named axfr time outs.  Add this, “pass proto ipv6-frag all”, to your ruleset somewhere near your antispoof rules to fix this.

Much of the issue is that the FreeBSD team has diverged their version of the pf firewall so far from the OpenBSD version that they cannot incorporate upstream fixes. I’m not making my situation any better by sticking with FreeBSD 9. Some of this is probably addressed in FreeBSD 10.

While this persists the best course of action is probably to make sure it works on OpenBSD first, then figure out how to deal with any FreeBSD issues.

The encryption battle goes on…

Senator Cotton on Apple and encryption

The person lying here is Sen. Cotton. He want’s you to believe that Apple just invented some uber secret tech and they are selling it wily nilly to any terrorist that walks into the Apple Store. Apple hasn’t done that. They’ve followed the same process as every other tech company. They have driven the defects, (bugs), out of their software to improve the user experience for their customers. At some point in time, following this process will invariably fix defects that could be used to operationally compromise the security of your devices.

The basic security algorithm that Apple is using is called RSA. It’s not perfectly secure. An attacker with enough computer time can compromise RSA without the key very simply using only division. The problem for the attacker is that the user of the cryptography gets to choose how many division operations the attacker has to perform.

The horse has been out of the barn on encryption since sometime between 1977 and whenever personal computers became ubiquitous in the first world. This is not an opinion, it’s a fact. It’s based on the mechanics of RSA encryption and it should be understandable to anyone with a grasp of middle school arithmetic.

RSA works because I can hide anything within the digital domain by picking two very large prime numbers and using them as the basis of my personal secret key. I can multiply those numbers together and I don’t need to keep the multiplicand secret. In fact, some else can use the multiplicand to send digital information that only I can read. An attacker has to factor that doubly large number and the only way to do that on today’s computers is to try different division operations until they find the only one set of factors that works. Since multiplication takes much much less time on computers than division, I get to choose how much work my attacker has to do by tuning the size of the original prime numbers. There’s more to it than that but the Wikipedia article on RSA encryption is a great place to start.


It’s not a good sign that no one in the audience noticed that the site’s been down for about two or three months. I’m not really sure because I missed the fact that the database for the site was on my old, about-to-be-retired database server. Thankfully it was an easy probable to solve.

Yet another open source journal