Now that I have it working at about the same level of reliability as the other plugins in the Newsboat repo I’ll pull out the dependency on dotenv and just tell the would-be consumer “get this credential into an environment variable, hardcode it, or do something else that feels safe to you.”

For myself, I’m weighing a couple of options because I’d like to do a little better than having a bunch of credentials sitting around in the plain.

Over the years I’ve handled this with mutt by combining gpg with mutt’s source config command:

1. Make a very minimal rc file in mutt’s config syntax that sets your user and password:

          set imap_user=you@example.com
          set imap_pass=yourimappassword1234

2. Encrypt that file with gpg:

   gpg -r yourkey@example.com –encrypt passwordfile

3. Use mutt’s source directive in your muttrc to decrypt the file on the fly and read in those two directives:

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

If you have gpg set up correctly, you’ll get a key authentication prompt when you run mutt. The credentials are never stored in the plain on disk, and you’ll get a gpg password prompt every now and then if you have other stuff going on, such as multiple accounts that each need to periodically source that config when you change between them. mutt’s source is just “do whatever is in this file,” same as zsh’s, so I eventually landed on a way to do the same thing in a shell environment:

$(gpg –decrypt ./setenv.sh.gpg)

That just decrypts setenv.sh.gpg and runs the commands inside, which can be just setting a bunch of environment variables in the current shell environment. The data is never decrypted to disk.

That seems like a good general solution that covers a lot of drive-by security scenarios.

In the process of working that out, I wondered about 1Password’s CLI tool. The few times I saw it mentioned the demos were for secrets management, not retrieval, but I took another look at the docs and it does have some interesting provisions for getting your secrets out of 1Password from the CLI.

Basically, when you use the op command’s run argument you can tell it to source in some environment variables from a .env file that uses op’s internal URI scheme to pull credentials out of your vault. An example resource reference looks like this:

op://Personal/Linkding/password

If you put that in an env file with a variable assignment, the op command can source it and pass it along to a shell command. So:

op run –env-file="$HOME/.env” – ~/bin/linkding.rb

… reads from a file that looks something like this:

LINKDING_USER="op://Personal/Linkding/username"
LINKDING_TOKEN="op://Personal/Linkding/credential"
FRESHRSS_USER="op://Personal/FreshRSS/username"
FRESHRSS_PASS="op://Personal/FreshRSS/credential"

… and supplies the linkding script with a value for this line:

token = ENV[‘LINKDING_TOKEN’]

If you’re already auth’d into 1Password and you’ve enabled integration between the CLI tool and the desktop app, then you don’t have to do anything. If you need to re-auth your 1Password instance, you’ll get a biometric prompt. If you’re ssh’d into a remote host where you wouldn’t get the biometric prompt, you can bypass that by setting OP_BIOMETRIC_UNLOCK_ENABLED=false but you’ll need to explicitly auth the 1Password CLI tool from the command line. It doesn’t seem to just fail over to a CLI auth.

So, handled the 1Password way, your .env file could remain unencrypted, but you’d probably be best off aliasing any scripts or commands you run where you want the op tool to interpolate your .env file.

It’s a little more cumbersome but maybe there’s benefit over the long haul from knowing that you just have to keep credentials in 1Password and can reference them elsewhere instead of maintaining an encrypted .env file. It’s also nice to have a biometric prompt or system auth vs. using gpg keys, which require you to have another password on hand (at least until 1Password quits punting on a gpg agent to pair with the ssh one).

For now I’ve only got enough stuff connected this way to use 1Password with FreshRSS and my Linkding plugin. Newsboat allows you to set your RSS service’s password with output from a shell command, so I’ve got that set to:

freshrss-passwordeval “op read op://Personal/FreshRSS/credential”

If I’m auth’d into 1Password, great: It just runs and sets the credential for NewsBoat. If I’m not, great as well: It just runs and tosses up a biometric prompt before proceeding.

I’m also using the env file pattern for Newsboat, for my bookmarking command:

bookmark-cmd “op run –env-file="$HOME/.env" – ~/bin/linkding.rb”

That’s because I don’t want to write my Linkding plugin to require any particular infrastructure. It just wants an environment variable, which is supplied by wrapping the script in the op run command with an –env-file switch. If someone wants to take the script and use another way to get the variable into their environment, or just decide to take their chances and hard-code it because they’re comfortable with that risk, they can. If I ever stop using 1Password I can similarly just figure out a new secrets backend and may be able to avoid rewriting a bunch of utility scripts if I keep using this approach. If I want to use one of my scripts on a host where I don’t have 1Password, well, there are other ways.

Update: I wondered about that mutt setup I have and ended up seeing what would happen if I replaced the whole “load mutt, source a gpg-encrypted file” thing with simple 1Password resource references. It works pretty well. If you’re signed into 1Password, it just works. If you’re not, you get a biometric prompt:

set imap_user=`op read op://Personal/MuttFastmail/imap_user`
set smtp_pass=`op read op://Personal/MuttFastmail/smtp_pass`
set imap_pass=`op read op://Personal/MuttFastmail/imap_pass`

Same caveats as with everything: If I ever end up wanting to use my mutt config on a machine I can’t put 1Password on, I’d need to go back to my old gpg file pattern.

I keep having to reinvent this every few years, and I always stitch it together from assorted sources, mostly because Google sort of shifts around now and then. So:

• Given a Gmail account with IMAP access turned on
• Given a Fastmail account using IMAP
• Given mutt, with your configuration in ~/.mutt and with muttrc and macros files.
• Given a working gpg config you can use to encrypt/decrypt

There are all sorts of ways to handle mutt config for assorted providers. The examples here are working right now, in early 2024. They probably have bits of cruft and lint because my config has been a work in progress since some time in the late 20th century.

Overview

You’re making profiles to do this: One for each of your accounts that will hold account specific config information. If you currently have a monolith config in mutt, you can lift a lot of stuff out of it and move it into a profile, then source the profile in your main muttrc.

You’re also going to make and encrypt a credential file for each account. Some people do this all in one file and use account hooks to make sure imap_user, imap_password and smtp_password are set correcctly depending on the account you’re operating in. I chose to make a file for each account.

You’re going to make macros that source the profiles when you want to switch between them.

0. Pre-config with Gmail and Fastmail

I’m not going to go into a ton of detail here:

• Gmail needs to have less secure app access turned on. Find it in your account settings. If you’re doing this for a work account, it may be your admin hasn’t enabled this. Have fun fighting city hall, in that case.
• If you have a GSuite admin, they need to have enabled all IMAP clients, not just OAuth ones.
• If you have 2FA turned on with Google, you will need to enable an application password.

For Fastmail:

• You need to have an app password set up for mutt. Settings -> Privacy and Security -> Integrations -> App passwords

1. The profile files

Make profile files for each of your accounts. I name them workplace.profile, fastmail.profile, etc. It doesn’t matter there’s no required convention. It’s a good idea to use the first one as the template for the second one.

This is an example of my Fastmail profile. Note line 6:

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

That’s where your credentials will come from. I’ll show that file next.

# -*- muttrc -*-
# Mutt sender profile : personal/default

unset folder
set smtp_authenticators = 'gssapi:login' # fastmail needs this
set imap_authenticators = ''
source "gpg -d ~/.mutt/passwords.gpg |" 
set spoolfile = "imaps://imap.fastmail.com"
set folder = "imaps://imap.fastmail.com/INBOX"
set postponed="+Drafts"
set hostname="yourdomain.com"
set signature= "~/.mutt/personal.sig"
set from= "Bob Jones <bob@yourdomain.com>"
set realname = "Bob Jones"
set smtp_url = "smtps://bobjones@fastmail.com@smtp.fastmail.com:465" # use your fastmail username, not your email address
set imap_user = "bobjones@fastmail.com" # use your fastmail username here, too

# set the status to show which profile I'm using
set status_format= "-%r-Fastmail: %f [Msgs:%?M?%M/?%m%?n? New:%n?%?o? Old:%o?%?d? Del:%d?%?F? Flag:%F?%?t? Tag:%t?%?p? Post:%p?%?b? Inc:%b?%?l? %l?]---(%s/%S)-%>-(%P)---\n"

unmy_hdr *

my_hdr From: Bob Jones <bob@yourdomain.com>
my_hdr Organization: yourdomain.com
my_hdr Sender: Bob Jones <bob@yourdomain.com>
my_hdr Return-Path: <bob@yourdomain.com>

# clear the existing mailboxes list
unmailboxes *

# load up mailboxes appropriate to this profile
mailboxes + "=Spam"
mailboxes + "=disposable"
mailboxes + "=Newsletters"
mailboxes + "=Sent"
mailboxes + "=Archive"

2. Make credentials files

For each account, you need to make a file for your credentials.

set imap_user=bob@bobjones.com
set imap_pass="klatu barada nikto"
set smtp_pass="klatu barada nikto"

Name it whatever. passwords-accountname works.

Once you’ve created the file, encrypt it with gpg:

gpg -r your-gpg-key@yourdomain.com -e passwords-fastmail

Test it:

gpg -d passwords-fastmail.gpg

Then shred the plaintext original:

shred -u passwords-fastmail

Make sure that your profile (from the previous step) is sourcing the gpg file in line 6 of my example, e.g.

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

3. Do a quick mid-config check

Might as well test it now. You can do that by sourcing one of your profiles in your muttrc:

source ~/.mutt/fastmail.profile

When you run mutt the first time in this login session, you should get a gpg prompt for your credentials so mutt can decrypt your password file and use it to log in.

If it’s working, now’s the time to make your second profile and credentials files using the above steps since it’ll be good to know what they’re all called for the next step, which is making macros.

4. Make macros

I keep my macros in their own file under ~/.mutt just to keep things modular. You can put these in your main muttrc. Whatever you prefer. If you have a separate file, make sure to source it in muttrc:

source ~/.mutt/macros

Now add something like this for each account:

macro index .cf '<sync-mailbox><enter-command>source ~/.mutt/fastmail.profile<enter><change-folder>!<enter>'
macro index .cg '<sync-mailbox><enter-command>source ~/.mutt/google.profile<enter><change-folder>!<enter>'

That just does one last sync, then sources your profile, then changes folders to the inbox of that profile.

Restart mutt. From the index, if all is working correctly, the macro .cf will source your fastmail.profile and the macro .cg will source your google.profile file (both of which also source/decrypt their respective credential files).

5. In conclusion

Once it’s all wired up and running, you should be able to switch back and forth between accounts with just a few seconds of latency as the inbox syncs on exit and the new inbox syncs on login.

The pleasures of mutt

I went on a mutt revival kick early last year. It remains a land of contrasts. I never end up sticking to it 100 percent of the time but instead prefer to use it as a quick triage tool: It’s easy to make macros and keybindings that speed up inbox processing. Sometimes it’s easier to just bail out to the web mail interface, but during the day it’s helpful to just burn through the inbox never taking my hands off the keyboard.

mutt scoring and color treatments

One last thing, I guess, since I’m documenting stuff. One of the reasons I like mutt for triage so much is my ability to add a little visual treatment to messages based on their scores. That makes it easy to see what in my inbox has more priority.

I’ve got this little script in my ~/.mutt:

#!/usr/bin/env ruby

require 'mail'
require 'tempfile'

# Wants a +/- integer, e.g. +20
score = ARGV.first

score_file = "#{Dir.home}/.mutt/scored"

msg = Tempfile.new('msg')

msg.write($stdin.read)

mail = Mail.read(msg)

from = mail.from.first

File.open(score_file, "a") { |f| f.write "score ~f#{from} #{score}\n"}

msg.close

msg.unlink

And I’ve got these macros in my ~/.mutt/macros file:

# Score messages
macro index,browser .sp "<pipe-entry>~/.mutt/mailscore.rb +5\n<enter-command>source ~/.mutt/scored<enter>" # score sender +5
macro index,browser .sP "<pipe-entry>~/.mutt/mailscore.rb +20\n<enter-command>source ~/.mutt/scored<enter>" # score sender +20
macro index,browser .sm "<pipe-entry>~/.mutt/mailscore.rb -5\n<enter-command>source ~/.mutt/scored<enter>" # score sender -5
macro index,browser .sM "<pipe-entry>~/.mutt/mailscore.rb -20\n<enter-command>source ~/.mutt/scored<enter>" # score sender -20

And I’ve got a few lines in my ~/.mutt/colors file:

color index cyan default "~n 0-2 !~p"
color index magenta default "~n <5"
color index brightyellow default "~n >15"
color index brightred default "~n >19"
#

The macros pipe a given message into the script, the script extracts the sender, and the script writes a line into my ~/.mutt/scored file. Then the ~/.mutt/colors file (which you need to source in muttrc) assigns colors to certain scores. I have a few other rules in ~/.mutt/scores, as well:

# Date-based scoring penalties -- older things fall down
score ~d>3d -1
score ~d>7d -3
score ~d>14d -10

score "~O" +10 # old = +10 so I don't miss it
score "~F" +20 # flagged = +20 so it stays in the interesting view for a while, even if old
score "!~p ~d>7d" -10 # not for me directly, getting old, let it fade away
score "!~l" +2 # to a known list, give it a bump

I want to have access to my Denote notes via SyncThing on a machine I don’t completely control (but is not, to be clear, operating in a hostile environment) and I want them to be encrypted, same as my org-journal files. I should probably just ask Prot, but as near as I can tell the clean way to encrypt notes in Denote is to add an “org.gpg” type to denote-file-types, like this:

(add-to-list 'denote-file-types
             '(org-gpg
               :extension ".org.gpg"
               :date-function denote-date-org-timestamp
               :front-matter denote-org-front-matter
               :title-key-regexp "^#\\+title\\s-*:"
               :title-value-function identity
               :title-value-reverse-function denote-trim-whitespace
               :keywords-key-regexp "^#\\+filetags\\s-*:"
               :keywords-value-function denote-format-keywords-for-org-front-matter
               :keywords-value-reverse-function denote-extract-keywords-from-front-matter
               :link denote-org-link-format
               :link-in-context-regexp denote-org-link-in-context-regexp))

It looks like a lot to do a little, but it’s just a clone of the org type that’s already in that list, with the extension changed. I suppose one could just alter the org type, but then you don’t have an unencrypted type if you want it.

With that in place, you can do:

(setq denote-file-type 'org-gpg)

… and anything you create with the denote command uses that type, with the correct extension. Given the right general config:

(require 'epa-file)
(epa-file-enable)
(setq org-crypt-key "foo@bar.baz")

… it all “just works,” with decryption handled transparently provided the gpg agent is set up correctly, and I preserve the option to have unencrypted notes for whatever reason I might want them at some point.

To get my existing notes into an encrypted state, I used this script:

#!/bin/zsh

encrypt_file() {
  local file_path="$1"
  local recipient="$2"
  local encrypted_file_path="${file_path}.gpg"

  gpg --encrypt --recipient "$recipient" --output "$encrypted_file_path" "$file_path"

  echo "File encrypted: $encrypted_file_path"
}

encrypt_files_in_directory() {
  local directory="$1"
  local recipient="$2"

  for file_path in "$directory"/*.org; do
    encrypt_file "$file_path" "$recipient"
  done
}

# Usage: ./encrypt_files.sh directory recipient_email
directory="$1"
recipient_email="$2"

if [[ -n "$directory" && -n "$recipient_email" ]]; then
  encrypt_files_in_directory "$directory" "$recipient_email"
else
  echo "Usage: ./encrypt_files.sh directory recipient_email"
fi

The mobile problem

The tradeoff with that approach is that your mobile use case gets harder. I can still do something like mosh my way in to the Mac Studio with Tailscale, I guess.

I have the nagging feeling that Emacs-centric note taking wouldn’t work great for me if I were dealing with a commute or other scenarios where mobile access is more important. Yes, there are beorg, Plainorg, and a few other options, but the syncing layer is the complicator. Some people seem to live fine just using git and maybe git-auto-commit, or just generally being more disciplined about their file use. I have generally felt better served by bespoke solutions, like you get with Obsidian, Things, and others. They’re still subject to the occasional screwup, but I don’t feel like I see them as often as I do with things that simply watch a file system and try to react appropriately.

I have been doing a little personal journaling about my preoccupations with mobile stuff. After tracing things back over the years, I recently realized that a lot of my fixation on getting stuff to work on a phone came from a pretty terrible time during the 2001 downturn.

All my teammates had been laid off and I was holding down a small network of Linux/open source sites that had previously involved a much larger team. If I didn’t want things to get out of control I had to keep an eye on them over the weekend. That mentality caused a lot of lines to blur and it took years to unblur them. I was an early iPad enthusiast because I’d internalized the idea that I should be able to do all kinds of work from anywhere at any time. Before that, I was really into the netbook thing because I could put an eeePC into a hip bag.

By the time I got to Puppet in 2012, working from home wasn’t a novelty or an aspirational goal: I’d been doing it for 13 or 14 years and was really glad to have an office to go to. Covid lockdown sparked a pretty bad reaction after the initial “let’s build a fire and sing songs while we wait for the drop ship” phase because lines started blurring again.

At the same time, just last week I had a pair of things to do in the afternoon and I’d written some thoughts down about one of the events that I wanted to review while I was out of the house. Well … apparently SyncThing hadn’t picked up on the changes before the machine I wrote them on went to sleep, so none of the other machines in the mesh — including a Synology I put SyncThing on for just these occasions — knew the notes existed.

At some point, “oh, no problem, I’ll just Tailscale in to the home network and WoL the Mac Studio so I can wake up SyncThing and then sync my changes down” loses all its charm.

Ugh. Need to stop before I talk myself into doing something rash and disruptive.

Hugo previews while working in ox-hugo

I’m not sure if there’s a better way to do this, but this is working for me:

(defun mph/start-hugo-server ()
  "Run Hugo server with live reloading and open the server URL in a browser."
  (interactive)
  (let* ((root (projectile-project-root))
         (default-directory root))
    (compile "hugo server -D --navigateToChanged" t)
    (run-at-time "3 sec" nil (lambda ()
                              (browse-url "http://localhost:1313")))))

(defun mph/stop-hugo-server ()
  "Stop Hugo server."
  (interactive)
    (kill-compilation))

(map! :leader
      (:prefix ("H" . "Hugo")
       :desc "Start Hugo Server" "S" #'mph/start-hugo-server
       :desc "Stop Hugo Server" "s" #'mph/stop-hugo-server))

I get a little Compiling treatment in the modeline while the preview server is running. My browser reloads any time I save my work.

What happened to V

I always sort of wondered what happened to V between the miniseries and the regular series. I had a vague sense it had gotten worse, but I was also a teenager and didn’t have a lot of critical faculties beyond “this seems sort of sucky and boring now.” Well, now I know: They got rid of the person who created it, made it cheaper, and tossed out what someone thought were the dumb parts, which were actually the good parts.

Interesting factoid:

V was watched in more than 33 million homes, which amounted to 40 percent of all TV viewership. (The most popular series in America today, Yellowstone, averages 13.1 million viewers per episode.)

I recently tried to dig up what’s considered “good numbers” in the streaming era and didn’t get many satisfying answers. Seeing that a modern phenomenon like Yellowstone pulls about 40 percent of V’s numbers is helpful. V was hyped all to hell at the time, so its “television special event” status probably skews things a little. (The M*A*S*H finale did 105.97 million total viewers, and that record may be impossible to break as streaming-driven atomization deepens.)

“The Phony Solidarity of the American Pundit Class”

I got to this post in The Nation after it sat on the read later pile for a while.

It’s very strange to see the post-2016 realignments continuing apace. This particular link targets the slice of the center-left-to-center-right commentariat that has learned to talk about “working people.” That tic — the “won’t somebody think of the working people” tic — feels symptomatic of a kind of elite capture all its own.

I wrote a few years ago:

“I have a lot of time for some heterodox thinkers. I wish ‘heterodox’ was narrow-able to something less broad than ‘a coalition of middle class trolls, rebadged culture warriors, people who hate how much they get ratioed, and well-meaning independent thinkers.’”

I think I may need to retract that. I was going through the podcast searching for an episode and saw a few descriptions here and there that tell me “heterodox” has stopped being a word one lands on after casting about for a better one, and has become a sort of branding exercise.