Removing the Desktop Bloat: Why Purging GNOME Forced Me to Write My Own 2FA Vault

Published on July 17, 2026
Tags: c99, ncurses, linux, window-maker, gnome, twm, cryptography

If you've been following my desktop journey, you know I've been on a bit of a minimalism kick lately. Back on January 21, I wrote about stepping away from the heavy, modern GNOME desktop environment to try out the classic, ultra-minimal twm. It was a massive breath of fresh air, but by April 30, I ended up shifting gears again-moving from twm over to Window Maker for a slightly more polished retro feel that still kept system resource usage practically at zero.

About two months ago, I decided to finish the job. I wasn't using GNOME anymore, so why keep all its residual bloat lying around on my hard drive? I opened up a terminal and purged every single remaining GNOME package from my machine. It felt incredibly satisfying to see hundreds of megabytes of redundant libraries vanish-until the unintended consequences caught up with me.

The Day 2FA Authentication Broke

Fast forward to about a month ago. I needed to log into GitHub to push some code updates and went to fire up ente auth to grab my 2FA token. Nothing happened. The app just flat-out refused to start. No window, no error message, just sat there not doing anything. (Waiting for gnome-keyring)

After a bunch of poking around in log files and running binaries manually, I finally found the culprit. When I stripped out the GNOME desktop environment, the package manager quite logically uninstalled gnome-keyring along with it. As it turns out, ente auth absolutely requires that specific background keyring daemon to function. I spent about two hours trying to reinstall just gnome-keyring as a standalone component, trying to force it to initialize and handle DBus communications properly without the rest of the desktop ecosystem there to support it. It was a massive waste of time, and frankly, completely defeated the purpose of moving to a minimal setup.

That's when I stopped and thought: I have my GitHub 2FA recovery codes anyway. Why am I wasting a afternoon wrestling with desktop bloat just to look up a six-digit number? I decided to ditch the app entirely and look for an alternative.

RFCs over Bloat: Building Lemon Vault

I spent a few hours surfing the web looking for a lightweight, self-contained 2FA client, but everything out there seemed to rely on heavy graphical frameworks, electron wrappers, or complex system-wide keyring daemons. The classic developer itch took over-how hard could it really be to just write my own tool?

I started digging into the core protocol specifications and pulled up two fundamental internet standards: RFC 6238 (which governs Time-Based One-Time Passwords, or TOTP) and RFC 4226 (which covers HMAC-Based One-Time Passwords). Reading through them, I realized the underlying math is remarkably simple. It's essentially just taking a base32 encoded secret key, hashing it alongside the current Unix timestamp step using HMAC-SHA1, and performing a bit of dynamic byte truncation to pull out a clean 6-digit number.

So, I sat down and built exactly what I needed. I call it lemon vault.

It's a simple, completely independent command-line utility written in C99-easily my favorite version of C-and it cuts out the nonsense entirely. It doesn't care about gnome-keyring, it doesn't need DBus, and it doesn't use a single pixel of X11 graphics libraries. Instead, it handles its entire interface right inside the terminal using ncurses.

How It Works Under the Hood

To keep the application entirely secure with almost zero-dependency, I paired standard C99 structures with OpenSSL for the cryptographic primitives.

The code is lean, incredibly fast, and runs perfectly on my lightweight Window Maker setup without dragging a mountain of unexpected dependencies along for the ride. It's an elegant reminder that when modern software stacks break under the weight of their own complexity, you can always drop back down to core standards, basic C, and build something clean yourself.