Skip to content
heldevia
Our own forgeAugust 18, 20261 min read

The validator that lies: an em dash versus our PGP signature

The reference security.txt validator accused our PGP block of being invalid. The real culprit: an em dash in a comment, and a library that decodes signed files as Latin-1. Lesson: validate with the validator's own tooling.

Also available in: Français

A field note — one problem, one diagnosis, one lesson.

Our security.txt (RFC 9116) is PGP-signed: security researchers who want to write to us can verify that the file really comes from us. When the time came to validate it, the internet.nl test delivered its verdict: "incorrect ASCII-armored PGP block". Invalid PGP block.

Except the PGP block was perfectly valid — gpg --verify passed without a murmur. The culprit was elsewhere, and the error message was lying.

The diagnosis, after a frustrating round trip: the validator's library decodes signed security.txt files as Latin-1, not UTF-8. Our file contained an em dash ("—") in a plain comment. That UTF-8 character, wrongly decoded, raised an encoding exception that the library caught and relabelled as a PGP error. The validator wasn't accusing the real culprit: it was accusing the signature, which had nothing to do with it.

The fix comes down to one rule: our security.txt is pure ASCII, short dashes and text without frills. The note is even written as a comment inside our source file, so the next person who edits it doesn't rediscover the problem.

The lesson goes beyond this particular case: when a validator contradicts you, validate with its own tooling before looking for the error on your side — and before "fixing" something that works. Error messages describe where an exception blew up, not always its cause.

← All articles

Ready to transform your business with AI?

Let's discuss how intelligent solutions can drive your next competitive advantage.