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 got an odd compliment last week: I learned that a few of my colleagues and I are considered “unnaturally collaborative.”

I won’t go into a lot of detail about the surrounding context, but it came down to, “we identified a potential source of conflict, one of us called a meeting, the other two showed up, we took turns talking, we arrived at rough consensus, and we trusted the convener to type up the notes (which they shared in advance) and send them upstairs.”

1. I think there’s a philosophical notion that anything that exists in time in space is in nature, and is therefore natural. Including, my philosophy instructor said with a wry grin for probably the 113th time in his career, purple unicorns, which must exist because time and space are infinite and therefore must contain virtually anything we could conceive. Including three directors who bias toward positive collaboration.
2. If there are any moral defects to be found here, they are in the imaginations of people who think three collaborative directors are the equivalent of purple unicorns.

Anyhow, I am honestly on the fence about whether it was a compliment or not. I once had a performance review downgraded because, my boss’s boss explained, my “how” dimension was so good that it was actually a liability, and he demanded it be lowered from a “5” to a “4” to reflect the dangers it posed to me and others.

But I do have a second story from this week that has caused me to feel a little less smug about it all.

There is a process at work that everybody hates. It involves multiple layers of functional and administrative staff, a bad mix of people who are conditioned to be process-oriented close readers and people who are understandably determined to cut any corners they can. There are also three warring tools ecosystems.

I hate it because it involves things I have been involved with and fixed in my past, but I am too new and don’t have enough standing or juice to get out and push, so while nobody is challenging my right to weigh in or make adjustments within my remit, I’m in the territory of “the little attitude thrusters you use in Lunar Lander” vs. “the warp nacelles of the Enterprise.”

So I’ve been making little adjustments here and there, identifying the places my own patch of process goes wrong most often, and making little adjustments. Including a few based on things I’ve observed but haven’t introspected, that I thought were helpful to the people who own that leg of the process.

Until today, when one of them did something slightly different from another one of them that seemed to be an utter refutation of all my proactive consideration for their needs.

So I broke down and asked what I was missing and they took a paragraph to expose me to a whole set of things that go wrong for them that aren’t exacerbated by what I was doing, but that what I was doing wasn’t helping; and how in other ways I was possibly slowing down another thing. Because I was being curious and helpful, but possibly not curious enough and maybe too helpful, at least in the wrong proportions at the wrong stages.

I’m giving myself a 4/5.

My heart was in the right place, but that’s table stakes.

Chrome profile launchers revisited

A couple of weeks ago I wrote a post sharing how to create GNOME launcher items for individual Chrome profiles. It’s a kind of cool thing to do if you want to just get straight to a given profile, and it works well with browser pickers like Junction or Browsers.

At some point, I noticed that one Chrome profile was ignoring my 1Password extension’s preference to stay in sync with the 1Password desktop app, so I kept having to log in to 1Password over and over: Every time you close your last Chrome window (as with any Linux desktop app and unlike on a Mac), an unsynced 1Password extension decides (wisely, sanely) that your auth’d session is over.

Years of Mac use have made it essentially impossible for me to leave a window open if I’m not using it. Why would I? It’s just visual clutter, and the app itself is sitting there on warm standby. So I kept geting logged out of 1Password and had to keep re-authing and it was unpleasant.

1Password has some guidance on how to get the extension to sync with the desktop again, and while I don’t want to sound churlish it amounts to “turn it off then turn it on again.” As an IT person, I respect that, but it didn’t do me any good. Removing and reinstalling didn’t help either, and I didn’t have a lot of confidence in that because the 1Password extension leaves some data behind when you remove it: Instead of needing your complete credentials (address, password, and the secret key), you just need the password when you reinstall.

So my last-ditch “avoid filing a ticket at all costs” play was to create a fresh Chrome profile and reinstall the plugin there, reasoning that the new profile’s sandbox wouldn’t have any legacy data in the form of cached stuff, or maybe a config file that changed between plugin versions and creates edge cases despite “mostly working.”

I turned off sync for the new profile, set up 1Password, then turned sync on. It worked as expected, even when all my other stuff got pulled in.

I flipped back over to the original Chrome instance giving me the problems and it was still stuck.

So, do I want to log back in to 1Password upwards of three dozen times a day, retrain myself to never close the last Chrome window, or just call it a day on getting fancy with profile launchers? Maybe another option is to point the launcher at the directory for the new, working profile, but as I sat here at 6 in the morning screwing around with Chrome profiles I re-remembered that over-optimization is a thing:

I wanted to save a few keystrokes here and there so I over-optimized a collection of things that I’ve observed in the past are individually complex and inconsistent, only a few of which are built with even one of the other components in mind. Something is eventually going to get weird in all that. And I don’t even like Chrome. I use it for work because we’re a Google shop and I don’t care if the data Google is harvesting reveals that I spend an ungodly amount of time in an invoicing system, a contract management system, and JIRA. There is no use case for using Chrome with a personal Google account. Firefox is fine for that.

So, lesson learned. Chrome is just “the work browser,” and I don’t have any other profiles. Done and done.

Storm stuff

We got off pretty light with the recent ice storm unpleasantness: Overnight without power, then a few downed branches and the death knell for a fence we’d hoped would hold out until spring, or at least fall onto our side of the yard. But it didn’t. It fell into the neighbor’s yard so we hauled away the part that couldn’t be propped back up and went looking for contractors.

I don’t know if there’s a secret to Angie’s List, but I’ve never cracked it. I put in a request, try to specify that email is going to be the best way to reach me, get hammered with phone calls (many of which are just hangups), and never feel like I end up with much choice.

This time around I got steered onto Yelp by a search engine, which then steered me into its contractor finder. Wow. Vastly different experience: A half-dozen emails before the morning was over, incredibly high responsiveness, and offers to come out and do estimates within the next day or two. I thought the project would be sitting until February or March, but it looks like today is New Fence Day.

To deal with the branches I ended up getting a Ryobi pruning saw to go with all my other 18v Ryobi stuff. I eyed larger chainsaws, but that just wasn’t the job at hand, storage is at a premium, and there’s not a foreseeable need given what’s on the property.

The pruning saw is great. I don’t see using it a ton, but it shares a battery with several other things, it’s very quiet, light, and compact, and it strikes a nice balance between “still obviously a dangerous tool” and “accessible.” Meaning, it’s easy to use and handle, but you’re still very clear after looking at it that it could fuck you up.

As I slapped the battery in and put on my eye protection, I remembered to pause and tell myself the micro-fiction I tell myself whenever I’m around power tools:

He approached the saw with the confidence of a middle-aged man who once took a shop class in junior high.

That’s not a completely accurate statement of the situation.

I did once take a shop class in junior high, but my bone-deep caution around tools was learned on the floor of an RV factory where there was no grumpy shop teacher yelling if you even looked distracted. Ask me to share my “the guy with the sheet of fiberglass, a table saw, no push stick, and no guard” story. But even that experience was a long time ago. Better to just pretend like I know a bit more than my fictional character, and way less than I actually do.