The trailing newline that broke every webhook signature.

frnxcode — Thu, 27 Aug 2026 21:31:33 +0000

I spent an evening convinced GitHub was sending broken webhook signatures. It wasn't. echo was.

The setup

Chngd's GitHub Marketplace webhook verifies every inbound event with HMAC-SHA256, comparing GitHub's X-Hub-Signature-256 header against a signature computed from the raw request body and a shared secret.

Every single request failed verification. Not intermittently. Every one, from the very first test delivery.

Where I looked first

The obvious suspects, in order:

Was I hashing the raw body, or a re-serialized/re-parsed version? Framework body-parsers are notorious for this: re-serializing JSON changes byte-for-byte content even when the data is "the same." Checked: raw body, untouched.
Wrong hashing algorithm or encoding (hex vs base64)? Checked against GitHub's docs: correct.
Timing-safe comparison bug? Checked: standard constant-time compare, no typo.

All correct. And it still failed, every time, deterministically. That determinism should have been the tell. A subtle logic bug fails sometimes or on specific payloads, not literally always.

Where it actually was

The secret itself was wrong. Not the value. The bytes.

I'd generated it and piped it into the environment file with echo $SECRET >> .env. echo appends a trailing newline by default. That newline became part of the stored secret string. GitHub's config field has no trailing newline, so their computed signature was based on the clean secret. My server was hashing with the secret plus an invisible \n, so every signature it computed was simply wrong, no matter what payload came through.

Nothing in any error message hinted at this. A signature mismatch looks identical whether the payload is wrong, the algorithm is wrong, or the secret has one invisible extra byte at the end.

The fix

printf '%s' "$SECRET" >> .env instead of echo. printf doesn't add anything you didn't put there.

The actual debugging move

If you hit a signature mismatch, don't start by re-deriving your verification code. Print the secret's length and a repr/quoted-string dump of it server-side first. A trailing newline shows up immediately in a repr; it's invisible everywhere else. That one check would have saved most of the evening.

The structural problem

echo vs printf is the proximate cause, not the real one. The real one is that a secret transited a human shell session and a hand-edited file with no validation step. Two things follow from that:

Secrets shouldn't be typed or piped through a terminal where avoidable. Generate them, inject via a secrets manager or CI/CD secret store, and verify the stored value (byte length, or a known-good HMAC against a test vector) before it ships.
Appending to a .env file from a shell is fragile on its own terms, independent of this bug. If the variable already exists in the file, you now have two entries, and which one wins depends on parser load order, not intent.

Neither of those is exotic. Both would have caught this before it ever reached "why is GitHub sending bad signatures."

Building an AI-drafted changelog tool with a GitHub App and Claude, solo

frnxcode — Thu, 20 Aug 2026 20:27:44 +0000

I've been building a hosted changelog tool called Chngd, mostly solo, using Claude Code as a daily collaborator rather than an autocomplete tool. Here's what the actual build looked like, technically, and a mistake that turned into the most useful lesson so far.

The core loop

Most changelog tools ask you to write the changelog. Chngd tries to remove that step: connect a GitHub repo, and it drafts a customer-facing changelog entry from your recent commits and PRs. You review, edit, and publish. Nothing goes out automatically.

The pipeline is simple on paper:

Pull commits since the last published entry
Filter out anything that's clearly not customer-facing (chore:, ci:, test:, docs: prefixes, [skip changelog])
Send what's left to Claude with a system prompt telling it the audience is non-technical end users, not developers
Get back structured JSON: a title and a markdown body
Show it in a dashboard for editing before publish

The filtering step matters more than I expected. Sending raw commit logs to a model produces a changelog that reads like a commit log with better grammar. Filtering internal-only commits first, before the model ever sees them, is what actually makes the output read like something a customer would want.

GitHub App vs OAuth+PAT

The lazier option was OAuth plus a personal access token. It's faster to build, maybe half a day faster. I went with a GitHub App instead, and the reason came down to one question: what does the paid tier actually need?

The free tier is a manual "sync now" button. The paid tier auto-syncs on push, via webhook, and auto-drafts (never auto-publishes, that stays a human action). That's fundamentally a GitHub App feature, not an OAuth+PAT one, because per-repo webhooks and installation-scoped access are how GitHub Apps work. Building it on OAuth+PAT first would have meant asking every existing user to redo their connection later. Paying the extra setup cost upfront avoided a migration I'd have hated doing after launch.

The mistake: Supabase RLS

This is the part worth writing about honestly instead of skipping.

I'm using Supabase for Postgres plus Auth, but all the actual data access happens server-side through Drizzle, not through Supabase's client libraries. Because of that, I treated Row-Level Security as something that applied to a pattern I wasn't using, and didn't think hard about it.

That was wrong. Supabase's REST API (PostgREST) sits in front of every table regardless of how your own server code talks to the database. The public anon key is baked into client-side JS by design, it's meant to be public. Without RLS enabled, that anon key can read and write any table with no policy in place, completely independent of whatever access patterns your app code uses.

Every table was exposed like this for weeks before I caught it, via a monitoring alert I'd nearly missed. I audited for tampering (none found), enabled RLS on all six tables, verified with both a direct Postgres query and a live curl test against the REST endpoint with the anon key, and set up Slack alerting so a future alert doesn't depend on me checking email.

The lesson: RLS is off by default in Supabase, and "I don't use the client library for this" is not the same as "this table is protected." If you're using Supabase as Postgres+Auth with a server-side ORM, check this today. It costs one migration and a few minutes.

Where it stands