“You’re Doing It Wrong”

The phrase is becoming prevalent. In 2017, most people in the world have larger voices than they do qualifications. Never before have podiums been instantly and freely available in so many styles, and never before would mankind had been able to realize the extent to which people confuse their large voices with qualifications. If you want to see beer muscles, go to the bar. If you want to see authority by volume, fire up your web browser.

Responsible people acknowledge this. I try to be responsible.

Irresponsible people attempt to propagate their ways of thinking, without thinking about said ways. These people exist in engineering fields such as computer science and are slightly more difficult to spot, on account of their logical tone. I have, through repeated exposure, discovered a number of earmarks of this false tone–signs that a person is driven more by irrational emotion than logical conclusion. One of the stronger indicators is the phrase, “you’re doing it wrong,” usually preceded by a possibility clause. Perhaps it is this possibility clause (“if A, then B”) that fools speakers into believing they remain logical.

Or perhaps they never truly believe they are being logical. Perhaps their consciences scream at them.

Perhaps they have learned to ignore the screams?

… Perhaps I should have started this list circa 2009, when I first began to notice the phrase’s prevalence. In 2017, I begin with the following. This list is ongoing, most recently updated on 2017-07-30. Check back periodically to find out how wrong you are.

The “You’re Doing It Wrong” List

N.B. I disagree with statements above (as they unravel into hasty generalizations), though assert neither agreement nor disagreement toward underlying stances. I will defend to death your right to say it, but I will not defend you.

grep -Rin 'doing it wrong' "$HOME/.weechat/logs" | wc -l
  • 2017-07-30 351
grep -Rin 'if .* doing it wrong' "$HOME/.weechat/logs" | wc -l
  • 2017-07-30 95

Verification in AUR Land Is Security Theater

Makepkg says to verify the key 449190F3235ABD3B. I decide today is the day I stop relying on –skippgpcheck. Wonderful.

From $HOME/.makepkg.conf, I set $GNUPGHOME to a freshly created gpg directory (as there are different kinds of “trust” in the world, and mixing personal keys with makepkg keys confuses two, separate kinds). This feature is not documented in makepkg’s man pages, but a contributor to makepkg mentions it here. I then run gpg –search-keys using my original $GNUPGHOME because hey, all it does is search, and something may very well be missing from the new $GNUPGHOME. Gpg, however, gives an error about dirmngr not running. I check dirmngr.conf. I try $( gpg-connect-agent –dirmngr ). “IPC connect call failed.” Fine, that’s another problem. There are still options, though, and I step over that rabbit hole.

I decide to verify the key manually, searching the PGP public key server at MIT. That’s a pretty big one, right? Sorry, the key is not there… All right, let’s try SKS. After all, that one is recommended in the GnuPG FAQ! That counts for something, right? “No results found.” Okay… I’ll just search for the key ID using a regular, Internet search engine.

DDG returns one result, and this link isn’t even it. Fine… perhaps DDG is small-time. Perhaps their web crawlers run on bread-powered ducks. Whatever. I seek the help of a multi-billion dollar corporation, which provides five results! The first is the same result from DDG! The remaining four are two copies each of the very signature error I foolishly thought, earlier this morning, that I could resolve through mere perseverance and rational protocol. These results were posted not by humans but by logging utilities.

The package that started this whole mess has 70 votes. It has a git repo with absolutely no references to signatures or pgp keys… Well, what would you do at this point? Do you trust the single entry from the CS department at Utrecht University? Did you even know that Utrecht had a university? … Had you even heard the word “Utrecht” once in your life before today?

Most importantly, do you honestly care at this point? The listed user has “debian” in his name. I can trust that, right?

Verification in AUR Land is security theater. It is not real security, because it is not feasible. Knowledgeable users may respond by pointing out PKGBUILD’s validpgpkeys, but aksr (the uploader) is just a regular user. Why should I trust him? Because I want to view PDF files with vi-like controls, that’s why. Such baseless trust is tantamount to –skippgpcheck, the very option that will earn your relay-chatting buttocks a paddling in #archlinux.

But seriously, you should trust him. I mean, look at all these.

I pity the people who spend as much free time as I do, wrestling imaginary monsters, and I apologize to the fine citizens of the Netherlands for implying their municipalities deserve anything less than international renown.

AUR verification is security theater.

ALSA Configuration of Loopback Device

# NoSuck.org
# 2017年02月13日、05時13分
# This file demonstrates ALSA configuration for a loopback device that simultaneously saves both input and output. Thanks go to debianuser from #alsa on the Freenode network for providing guidance.

■ aplay -L | grep '^sysdefault'

■ aplay -l | grep PCH
card 0: PCH [HDA Intel PCH], device 0: ALC898 Analog [ALC898 Analog]
card 0: PCH [HDA Intel PCH], device 1: ALC898 Digital [ALC898 Digital]
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]

■ cat /etc/modules-load.d/snd-aloop.conf

■ cat /etc/modprobe.d/alsa.conf
options snd_hda_intel index=0
options snd_aloop index=1

■ cat ~/.asoundrc
defaults.pcm.dmix.!rate 48000
defaults.pcm.dmix.!format S16_LE
pcm.multi {
  type multi
  slaves.a.pcm "dmix:PCH"
  slaves.a.channels 2
  slaves.b.pcm "dmix:Loopback"
  slaves.b.channels 2
  bindings.0 { slave a; channel 0; }
  bindings.1 { slave a; channel 1; }
  bindings.2 { slave b; channel 0; }
  bindings.3 { slave b; channel 1; }
pcm.both {
  type route
  slave.pcm "multi"
  ttable.0.0 1
  ttable.1.1 1
  ttable.0.2 1
  ttable.1.3 1
pcm.!default {
  type asym
  playback.pcm "plug:both"
  capture.pcm "plug:dsnoop:PCH"

# Record.
■ ffmpeg -y -f alsa -ac 1 -i sysdefault:CARD=PCH -f alsa -i plughw:Loopback,1 -filter_complex [0:a][1:a]amerge=inputs=2 output.flac

# Record input only.
■ ffmpeg -y -f alsa -ac 1 -i sysdefault:CARD=PCH output.flac

# Official example.
■ cat /usr/share/alsa/cards/Loopback.conf

Configuring Mailto in an XDG Environment

It’s time to configure your web browser to open mailto links using mutt. You know you want to.

Nimble mutt action.

You also know it’s going to be tricky, as mutt is a command-line program, and command line programs are like appliances that refuse to die. They work well but don’t match your cupboards from IKEA made from particle board. Still, mutt has a nice trick up its sleeve: It can process mailto arguments on the command line.

mutt mailto:mutt-users-request@mutt.org?Subject=Subscribe%20Mutt%20Users

There is only one problem: Mutt is unable to process every mailto attribute and fails on attributes it does not recongize (like Body).

mutt mailto:mutt-users-request@mutt.org?Subject=Subscribe%20Mutt%20Users&Body=subscribe
> Stopped

[The above mailto link is taken directly from the official mutt mailing list page. Mutt’s fleas have a good sense of irony.]

The solution is to wrap mutt in a script that parses mailto links. Using a whitelist of valid attributes has an added benefit of heightening security, as potentially malicious attributes are automatically discarded.

Use that script in a desktop file.

cat "$HOME/.local/share/applications/mutt-mailto.desktop"
> [Desktop Entry]
> Type=Application
> Name=Mutt Mailto Handler
> GenericName=MUA
> Comment=Supposedly sucks less.
> Exec=/home/ingvar/MuttMailto
> Terminal=true
> MimeType=x-scheme-handler/mailto
> NoDisplay=true

Inform the desktop environment.


Make it stick.

xdg-mime default mutt-mailto.desktop x-scheme-handler/mailto

Now you’re cooking with gas.

You Are Managing Passwords Wrong: LastPass and Friends

In an uncharacterstic move, I type now not to my future self but to the entire world. The importance of my announcement justifies this decision: If you use LastPass, your conception of security is wrong. Expert knowledge is not necessary to understand why, and the only postulate to which you must agree is that of chains only being as strong as their weakest links.

I do not use LastPass, though I consider its accessibility and ease of use a boon to the security ecosystem. I even recommend LastPass to others (family and friends with little inclination toward computers, for example). In recommending LastPass, I do not reveal that its foundation is flawed. Such knowledge is irrelevant to the people to which I recommend LastPass, as these people are not able to customize their window managers. If you are not able to customize your window manager to the point of emulating keypress events from menu items, the remainder of this article will be of little use to you. If, on the other hand, you are, we will be using the following tools:

The end result looks like this (using Openbox):

Qutebrowser is great.
More secure and more versatile than any password service.

The window manager’s main menu is opened, and the password menu (P) is selected. A category is chosen (A), followed by the actual item for which a password is retrieved (A). The final item is an encrypted password file that is decrypted by GNU Privacy Guard, with the resulting password output by xdotool to whatever program currently accepts input. Already, we have uncovered three advantages over LastPass and friends…

  • Works with any program, not just with forms displayed in web browsers with password plugins installed.
  • Fewer entry points. Fewer links in the chain lower the chances of one being weak (the unknown unknowns).
  • Customizable and extendable.

… and one quality that LastPass would like to claim a disadvantage:

  • Limited to terminals with access to encrypted password files.

I claim this an advantage, because once again, I know that chains are only as strong as their weakest links. Today, it is raining outside. I look outside, and I see clouds overhead. My neighbor sees the same clouds. My neighbor might think those clouds can hold critical documents, but I keep mine locked in a file cabinet in the basement. This is not an issue of trust so much as one of common sense and convenience–because the file cabinet is closer, and tomorrow could very well be a sunny day.

Then again, the whole point of having clouds hold documents is for people to be able to go one town over and still see those documents hanging in the sky. I have had enough of this analogy. If you require access to a critical document on a terminal to which you cannot trust to store an encrypted password file, you are managing passwords wrong. Use “12345” for those. They are not secure, and no quantity of helmets will protect you from sharks while diving. I am an analogy machine.

Critical documents should only be accessed from terminals you are able to claim as your own. You might think you need your online banking password available on any computer with Internet access, but I bet you could count on one hand the number of computers you actually use. Send money, record secrets, and store nude photographs on your own computers, not on some cloud on a cloudy day.

Then when you have separated cruciality from “12345,” make some noise:

for (( u = 0 ; u < uCount ; u++ )) ; do
# Output is concatenated to maintain continuity of demonstration.
# For the real deal, use gpg's --output option and forego looping.
gpg --armor --gen-random 2 "$uLength" >> /mnt/hdd_not_ssd/entropy.txt

Look at the randomness. These are your passwords. Break them into variable-length chunks, and store them in files. Don’t let your editor back them up, and remember that extra caution during the setup procedure lasts forever:

echo "set nobackup" >> ~/.vimrc
echo "set nowritebackup" >> ~/.vimrc
vim /mnt/hdd_not_ssd/entropy.txt
# Saved to these:

Gnome-keyring, python-keyring, and libsecret would only be redundant links in your chain. Do not bother assessing their strengths, because they are superfluous. Instead, concoct a good master passphrase and generate a key from GNU Privacy Guard:

gpg --full-gen-key

Encrypt your password files as soon as possible:

gpg --list-keys
> /home/nosuck/.gnupg/pubring.gpg
> ------------------------------
> pub rsa2048/DEADBEEF 2015-04-01 [有効期限: 2016-04-01]
> uid XXX
> sub rsa2048/LIVEBEEF 2015-04-01 [有効期限: 2016-04-01]
gpg -ear "$sKeyId" /mnt/hdd_not_ssd/gmail.txt
gpg -ear "$sKeyId" /mnt/hdd_not_ssd/japan_net_bank.txt
gpg -ear "$sKeyId" /mnt/hdd_not_ssd/freenode.txt
shred /mnt/hdd_not_ssd/gmail.txt
rm /mnt/hdd_not_ssd/gmail.txt
# ... and so on.

Finally, output passwords through your window manager, using xdotool. Though this link is arguably stronger than even physically typing a password on a keyboard, it is still the weakest in our short and sturdy chain:

xdotool type --clearmodifiers --delay 5 "$( gpg -qd "$pGmail" )"

You can also use passwords with programs clever enough to take input from places other than GUI toolkits:

cat ~/.muttrc
> set smtp_pass = `gpg -qd /mnt/no_longer_matters/gmail.asc`
cat ~/.offlineimaprc
> remotepasseval = Password ( "/mnt/no_longer_matters/gmail.asc" )

When you’ve memorized your master passphrase, adjust time-to-live settings for its prompting. The following settings will make gpg-agent require master passphrase input only once per day–not as often as it should, but I have little faith in you. Specify in seconds:

echo "default-cache-ttl 43200" >> ~/.gnupg/gpg-agent.conf
echo "max-cache-ttl 86400" >> ~/.gnupg/gpg-agent.conf

You can also force re-prompts for any subsequent password accesses. This is good to do before leaving your computer unattended. Make this command accessible. Mine is never more than four keystrokes away (the “R” item in the animated demonstration). It is a good idea to force a reprompt on system idle and sleep events, as well:

echo RELOADAGENT | gpg-connect-agent -v

… and that is the optimal convenience you can get out of a truly secure password management system. Passwords entropy level is high; password retrieval is convenient, with the master passphrase only required as often as configured; lastly, the chain of software from password request to password retrieval is as short as feasibly possible.

.. and I didn’t even mention LastPass being closed-source as a deal-breaker from the get-go.