Security

A Hugo build is a folder of files. Nothing executes, nothing talks to a database, nothing parses user input. The interesting attack surface isn’t the content — it’s the server you put in front of it, and for years that meant an nginx image carrying a config language, a module system, and a package manager I never used.

This blog now runs on static-web-server instead. Here’s the compose file that serves it, and what each hardening line actually buys.

It happens to almost everyone, eventually.

You stage your changes, type git commit -am "wip", push — and a few minutes later realize that id_rsa (or .env, or credentials.json) was sitting in the working directory the whole time. The file is now in the remote, in every clone, in every CI cache, and worst of all: in the git history, where a simple git rm won’t touch it.

This post walks through fixing exactly that scenario with BFG Repo-Cleaner — a tool purpose-built for ripping unwanted blobs out of git history.

GitLab access tokens expire. Project tokens, group tokens, personal access tokens — all of them. The trouble is that the expiration dates live in different corners of the UI, and you usually find out one expired the morning a CI pipeline mysteriously starts failing.

gitlab-token-expiration is the small tool I wrote to never have that morning again.

Every time I needed to inspect a JWT, I ended up doing the same thing: paste it into a website I half-trust, squint at the payload, then close the tab feeling vaguely guilty. I wanted a local tool, scriptable, that could both decode tokens and mint them for testing. So I wrote jwt-cli.

shred is the tool everyone reaches for, but it’s far from the only one — and on modern SSDs and journaling filesystems, it’s often the wrong one. This post covers the alternatives: secure-delete, wipe, blkdiscard, hdparm, nvme-cli, and the macOS equivalents — plus why full-disk encryption is now the recommended approach for serious data hygiene.