---
title: How to report a security problem
url: https://namegarage.com/blog/how-to-report-a-security-problem
author: Namegarage
date: '2026-09-19'
description: There is now a vulnerability disclosure policy at /security/, an address
  to send a report to, a public key to encrypt it with, and a signed security.txt
  so the machines can find all three. No bounty, but an acknowledgment within five
  business days and no lawyers.
---

# How to report a security problem

If you find a security problem on this site, you should not have to guess
where to send it, whether anyone will read it, or whether reporting it is
safe. As of today, all three have a written answer.

## The policy

[namegarage.com/security/](/security/) is our vulnerability disclosure
policy. It is short. It says what is in scope (this site, its subdomains,
every form, and the endpoints those forms post to), what is not (denial of
service, social engineering, the third parties we build on, which run
their own programs), and what we ask of you: stop at the minimum needed to
show the problem, do not read or keep data that is not yours, and give us
up to 90 days before going public.

In return we commit to acknowledge every report within five business days,
keep you informed until it is fixed, and not pursue legal action against
research that follows the policy in good faith. There is no paid bounty —
this is a one-person portfolio, not a company with a security budget — but
there is a thank-you, and we mean it.

Like our Terms and Privacy pages, the policy is versioned: every version is
published at a permanent dated address with the SHA-256 hash of its source,
and a change is a new version, never an edit. What the policy said on the
day you tested stays provable.

## The address, and a key

Reports go to **security@namegarage.com**. If you would rather not send the
details in plain text, there is an OpenPGP key at
[/security/pgp-key.txt](/security/pgp-key.txt) to encrypt them with. Its
fingerprint, which the policy page also prints, is:

```
fc561d0a77ff466db2f59c7147db09db5de7c0b4
```

## The machine-readable version

Security scanners and researchers' tools look for a file called
`security.txt` at a well-known address, defined in
[RFC 9116](https://www.rfc-editor.org/rfc/rfc9116). Ours is at
[/.well-known/security.txt](/.well-known/security.txt), and it carries the
same three things — the contact, the key, and a link to the policy — in the
format the RFC lays out.

Two details are worth knowing. The file is **signed** with that same key
(an OpenPGP cleartext signature, the RFC's recommendation), so a copy of it
can be checked against the published key: import the key, run
`gpg --verify` on the file, and the reported fingerprint should be the one
above. And its `Expires` line is renewed automatically with every
deployment, so it never quietly goes stale — a `security.txt` past its
expiry is one the RFC tells readers to disregard.

The older spelling, `/security.txt` at the site root, redirects to the
well-known one, so tools that still look there land in the right place.

## Why now

Nothing happened. That is the point of doing this before something does:
the day someone finds a problem, the way to tell us is already written
down, and the promise about how we will treat them was made before we knew
who they were.