Blogging Roller

Twenty-five years of Roller, and suddenly a backlog

Dave Johnson — Mon, 28 Sep 2026 21:35:17 +0000

It's crazy that I started working on a project called Roller twenty-five years ago this month, and next year Apache Roller will celebrate its 20th year as a top-level Apache project. Somehow I am still working in this same codebase.

Roller has been a pretty sleepy project for a long while, only making releases in response to incoming vulnerability reports or dependecy upgrades. But recently, there has been a resurgence in Roller development driven by artificial intelligence. In August and September, a handful of folks reported a total of 26 security vulnerabilities, all comprehensive with steps to reproduce and suggested fixes, and most were legit problems in Roller. (post edit: yes, I am implying these vulnerabilities were found by and reports written by AI)

The 2026 security batch, from first report to Apache Roller 6.1.6.

Around the same time, long-time Roller contributor Matt Raible made a series of AI-powered contributions, including a port of Roller from the old Java EE APIs to the Jakarta APIs and a bunch of other improvements. Suddenly, the sleepy little Roller project has an actual backlog!

Dealing with the 26 vulnerability reports was a serious project and I made the most of AI. Each report requires a tedious twenty-something-step process, so I developed a system for triaging the reports into separate directories and recording the status of each in a series of Markdown files and Obsidian Tasks. I encoded that into an AI "skill" called roller-security that can be used by Claude and Codex. I used that skill to walk me through the work, draft emails, and edit the web forms needed to request, edit and publish CVEs.

AI was helpful in dealing with the vulnerabilities, but we would have gotten nowhere without Roller contributors stepping up to help out. Thanks to Greg Huber, Matt Raible and Michael Bien for many PR reviews, testing release candidates and many contributions over the years! And, thanks to reporters meifukun, n0mi1k, m4dn355, Ivan Iushkevich (Steph) and 姬珏 (CyberLeo) for the research and for following the ASF process.

The security vulnerabilities are still trickling in, so you'll see a Roller 6.1.7 sometime soon, and later a Roller 7 release built on the Jakarta EE APIs.

GitHub Actions and DigitalOcean lessons from Claude

Dave Johnson — Tue, 2 Jun 2026 21:30:00 +0000

I would say that 99% of the code in the Investor Ping's backend and iOS app was written by LLMs, but I did not vibe code it. My definition of vibe coding is when you use an LLM to write code that you do not review or even read. Nope, I ran the project like I always do with design docs, issue tracking, pull requests and CI/CD sandbox and production deploys (in this case to DigitalOcean). I review all code and try to enforce some architectural constraints, mostly about separation of concerns, configuration and secrets management; but maybe less so in the iOS app because I am new to iOS and Swift.

Despite that, I ended up with some poor security practices baked into my codebase. I knew that would happen given the volume of code I was generating and my desire to move fast.

So, I worked with Claude Code to create a comprehensive security review and Claude found eighteen issues that should be fixed; most were in GitHub Actions workflows and secrets; the rest were vulnerable NPM dependencies and application level problems. The review created is an impressive document that explains each problem and how to fix it. Claude made a list of the top five things to fix and three of them were good lessons to learn.

📍 Pin third-party GitHub Actions to a commit SHA

The first item is to pin the third-party GitHub Actions used in my workflows to specific commit SHAs to reduce the chance of a supply chain attack. This seems reasonable and easy to do.

# Before — tag reference, mutable
- uses: actions/checkout@v4

# After — immutable SHA, version tag in comment for humans
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

🔐 Lock-down SSH with StrictHostKeyChecking=yes and ForceCommand

The second item is about how CI/CD accesses the production servers via SSH using a 3rd party GitHub Action and StrictHostKeyChecking=no. The workflow uses SSH to do deployment: to write config and secrets to a Docker Compose file and start up my containers. I think this is the most serious issue found. We don't want CI/CD to have the keys to the kingdom.

The fix is to add StrictHostKeyChecking=yes and use an SSH feature called ForceCommand to lock the SSH key down so that it can only run one specific script on the remote host, and to get the secrets to the hosts via a diferent route: a script I run on my laptop and a different SSH key.

On the host, restrict the CI key in ~/.ssh/authorized_keys to just the deploy script:

command="/usr/local/bin/deploy.sh",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAA...ci-key... ci-deploy@github

In the workflow, drop the third-party SSH action and pin the host key:

- name: Deploy
  env:
    DEPLOY_HOST: ${{ secrets.DEPLOY_HOST }}
    SSH_KEY:     ${{ secrets.DEPLOY_SSH_KEY }}
    KNOWN_HOSTS: ${{ secrets.DEPLOY_KNOWN_HOSTS }}
  run: |
    install -d -m 700 ~/.ssh
    printf '%s\n' "$SSH_KEY"     > ~/.ssh/id_ed25519  && chmod 600 ~/.ssh/id_ed25519
    printf '%s\n' "$KNOWN_HOSTS" > ~/.ssh/known_hosts && chmod 600 ~/.ssh/known_hosts
    ssh -o StrictHostKeyChecking=yes -i ~/.ssh/id_ed25519 \
        deploy@"$DEPLOY_HOST" deploy

🪖 Use least-privilege DigitalOcean access keys

Third, CI/CD runs Terraform with an all-powerful DigitalOcean API access token when some workflows only need a couple of permissions.

DO supports custom-scoped tokens (Control Panel → API → Generate New Token → Custom Scopes). Create one per workflow, stored as a separate GitHub secret, e.g. a token just for registry management:

jobs:
  tf-registry:
    environment: prod              # required reviewer before apply
    env:
      # token scopes: registry:read, registry:create, registry:delete
      DIGITALOCEAN_TOKEN: ${{ secrets.DO_TOKEN_REGISTRY }}
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - uses: hashicorp/setup-terraform@b9cd47afb6f8aabd99b34a4673bf25b95f6d4d0d # v3.1.2
      - run: terraform -chdir=terraform/registry apply -auto-approve

The fourth and fifth items were NPM dependencies with critical vulnerabilities that need an update. I feel like I need to learn some lessons in this area.

It took me maybe three Claude Code sessions, a couple of afternoons, to deploy fixes for those five problems plus two others. In the end it was nine pull requests and ~2,200 added / ~630 deleted lines of code.

The overall lesson: rapidly producing code with LLMs leads to security and other problems, because try as you may, you can't review every line. But a great LLM harness like Claude Code can search and probe your codebase from every angle and help you find and fix those problems quickly.

Windows security

Dave Johnson — Sat, 3 Feb 2007 23:34:15 +0000

Usually I find a couple of contradictory stories every time I read the feeds. Here's a pair from today's session. First via John Gruber.

Bll Gates in Newsweek: Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine.

And next, via John Robb, I found:

Spencer Kelly, BBC: We set up a poor Windows XP machine with no firewall or anti-virus software. Connecting it to the internet would be like throwing it into a lion pen with raw meat strapped to its hard drive. How long would it be before we were hit by something nasty on the net? Hours, minutes? As it turned out - eight seconds!

Of course Bill may have been talking about Vista, even though he did not qualify. Maybe Vista is better, but I wouldn't count on it. Initial reports don't sound so good (Vista users: keep your speakers and microphones turned off).