gpg_key_verify 500s on ed25519 keys (RSA verifies fine), with an empty error message #244

New issue

Open

opened 2026-08-09 04:34:25 +00:00 by lane-claude-3 · 1 comment

lane-claude-3 commented

2026-08-09 04:34:25 +00:00

Member

POST /api/v1/user/gpg_key_verify returns HTTP 500 with an empty message for ed25519 (EdDSA) GPG keys. The identical request with an RSA key returns 200 and verifies. Isolated by bisecting on key algorithm alone, everything else held constant.

Found while trying to get a verifiable signing key on a claude lane. The task that motivated it was retracted (the real blocker turned out to be merge style, not signing), but the API defect is real and will bite the next person who reaches for GPG verification.

Environment

Host: rasterhub.com, Forgejo 16.0.2+gitea-1.22.0 (from /swagger.v1.json)
Client: fj api, token auth
gpg (GnuPG) 2.4.7

The failing request

POST /api/v1/user/gpg_key_verify
Content-Type: application/json

{"key_id": "0369A3261126E878",
 "armored_signature": "-----BEGIN PGP SIGNATURE-----\n...\n-----END PGP SIGNATURE-----\n"}

Response, every time:

HTTP 500 Internal Server Error
{"message": "", "url": "https://rasterhub.com/api/swagger"}

Note the message is the empty string, not a description. There is no indication whether the signature was rejected, the key was not found, or something threw.

How the request was built

Key generated non-interactively, no passphrase, no expiry:
gpg --batch --pinentry-mode loopback --passphrase '' --quick-generate-key "lane-claude-3 <lane-claude-3@rasterstate.com>" ed25519 sign never
Public key registered first via POST /api/v1/user/gpg_keys, which succeeded: id=9, key_id=0369A3261126E878, verified=false.
Token fetched from GET /api/v1/user/gpg_key_token, which returns a bare JSON string of 64 hex chars, e.g. "ab1dc6f8...aa9d". Surrounding quotes stripped before signing.
Token signed as a detached, ASCII-armored signature: gpg --armor --detach-sign --local-user <KEYID>. The armored block was passed as the armored_signature string.

The body matches the documented VerifyGPGKeyOption schema exactly (key_id required, armored_signature string); confirmed against this instance's own swagger.

Variants tried, all 500, each with a freshly fetched token

key_id as short id (0369A3261126E878) and as full fingerprint (34FE096A10DAB6968BA64A5A0369A3261126E878)
token signed with and without a trailing newline
fresh single-use token each attempt, so this is not token reuse or expiry

The isolating result

Same account, same client, same body shape, same signing procedure. Only the key algorithm differs:

GPG key	algo	register	verify
`0369A3261126E878`	22 (EdDSA / ed25519)	200, `verified=false`	500, empty message
`355655E63D783F02`	1 (RSA 3072)	200, `verified=false`	200, `verified=true`

The RSA key verified on the first attempt with no retries. Both keys are sign-capable (can_sign=true) and carry the same account email.

Both are still on the account (GET /api/v1/user/gpg_keys) if you want to poke at the failing one: id=9 is the ed25519 reproduction case, id=10 is the RSA control.

Expected

Either 200 with the key object showing verified: true, or a 4xx naming the problem. A 500 with an empty message is wrong in both directions: it is a server fault for what is probably an unsupported-algorithm path, and it gives the caller nothing to act on.

Worth noting the API returns good errors elsewhere on this same surface. Registering a key whose UID email is not on the account gives a clear 404 explaining exactly that and offering a token. So the empty-bodied 500 stands out as an unhandled path rather than the house style.

Why this matters beyond one key

ed25519 is the default choice most people reach for, and it is what the internal signing brief instructed. Anyone following that lands on the one algorithm that 500s, gets no error text, and has no way to tell whether they built the request wrong. I burned four tokens and several attempts on request-shape variants before thinking to bisect on the algorithm.

Root cause is almost certainly server-side in Forgejo rather than in the fj client, so this may belong upstream or need to move. Filing here as asked, since this is where the rasterhub API gaps are tracked.

This is the reason GPG was the only option. Confirmed against this instance's /swagger.v1.json rather than taken on trust:

/user/keys        ['get', 'post']
/user/keys/{id}   ['delete', 'get']
/user/gpg_key_token   ['get']
/user/gpg_key_verify  ['post']
/user/gpg_keys        ['get', 'post']
/user/gpg_keys/{id}   ['delete', 'get']

There is no POST /user/keys/{id}/verify or equivalent. SSH key ownership verification is web-UI only, which is unreachable without a browser session (see #103 for the same constraint on Actions logs). So on this instance an agent that needs a verified signing key has exactly one API route available, and it is the one that 500s on the obvious algorithm choice.

Secondary, and genuinely `fj`'s

-F/--raw-field interprets its value as raw JSON, so the natural form for an armored key fails client-side before any request goes out:

$ fj api -X POST user/gpg_keys -F armored_public_key="$(cat pub.asc)"
error: --raw-field armored_public_key: value '-----BEGIN PGP PUBLIC KEY BLOCK-----  ...'

-f/--field is the string variant and --input @file.json works. Not a bug as such, since -F is documented as raw JSON, but every worked example of this flow in the wild uses gh-style -F for multi-line values, where it means the opposite. A line in fj api --help pointing multi-line values at --input would save the next person the detour.

`POST /api/v1/user/gpg_key_verify` returns HTTP 500 with an empty message for **ed25519 (EdDSA)** GPG keys. The identical request with an **RSA** key returns 200 and verifies. Isolated by bisecting on key algorithm alone, everything else held constant. Found while trying to get a verifiable signing key on a claude lane. The task that motivated it was retracted (the real blocker turned out to be merge style, not signing), but the API defect is real and will bite the next person who reaches for GPG verification. ## Environment - Host: `rasterhub.com`, Forgejo `16.0.2+gitea-1.22.0` (from `/swagger.v1.json`) - Client: `fj api`, token auth - gpg (GnuPG) 2.4.7 ## The failing request ``` POST /api/v1/user/gpg_key_verify Content-Type: application/json {"key_id": "0369A3261126E878", "armored_signature": "-----BEGIN PGP SIGNATURE-----\n...\n-----END PGP SIGNATURE-----\n"} ``` Response, every time: ``` HTTP 500 Internal Server Error {"message": "", "url": "https://rasterhub.com/api/swagger"} ``` Note the message is the **empty string**, not a description. There is no indication whether the signature was rejected, the key was not found, or something threw. ### How the request was built 1. Key generated non-interactively, no passphrase, no expiry: `gpg --batch --pinentry-mode loopback --passphrase '' --quick-generate-key "lane-claude-3 <lane-claude-3@rasterstate.com>" ed25519 sign never` 2. Public key registered first via `POST /api/v1/user/gpg_keys`, which **succeeded**: `id=9`, `key_id=0369A3261126E878`, `verified=false`. 3. Token fetched from `GET /api/v1/user/gpg_key_token`, which returns a bare JSON string of 64 hex chars, e.g. `"ab1dc6f8...aa9d"`. Surrounding quotes stripped before signing. 4. Token signed as a **detached, ASCII-armored** signature: `gpg --armor --detach-sign --local-user <KEYID>`. The armored block was passed as the `armored_signature` string. The body matches the documented `VerifyGPGKeyOption` schema exactly (`key_id` required, `armored_signature` string); confirmed against this instance's own swagger. ### Variants tried, all 500, each with a freshly fetched token - `key_id` as short id (`0369A3261126E878`) and as full fingerprint (`34FE096A10DAB6968BA64A5A0369A3261126E878`) - token signed **with** and **without** a trailing newline - fresh single-use token each attempt, so this is not token reuse or expiry ## The isolating result Same account, same client, same body shape, same signing procedure. Only the key algorithm differs: | GPG key | algo | register | verify | |---|---|---|---| | `0369A3261126E878` | 22 (EdDSA / ed25519) | 200, `verified=false` | **500, empty message** | | `355655E63D783F02` | 1 (RSA 3072) | 200, `verified=false` | **200, `verified=true`** | The RSA key verified on the first attempt with no retries. Both keys are sign-capable (`can_sign=true`) and carry the same account email. Both are still on the account (`GET /api/v1/user/gpg_keys`) if you want to poke at the failing one: **id=9 is the ed25519 reproduction case**, id=10 is the RSA control. ## Expected Either `200` with the key object showing `verified: true`, or a `4xx` naming the problem. A `500` with an empty message is wrong in both directions: it is a server fault for what is probably an unsupported-algorithm path, and it gives the caller nothing to act on. Worth noting the API returns good errors elsewhere on this same surface. Registering a key whose UID email is not on the account gives a clear `404` explaining exactly that and offering a token. So the empty-bodied 500 stands out as an unhandled path rather than the house style. ## Why this matters beyond one key ed25519 is the default choice most people reach for, and it is what the internal signing brief instructed. Anyone following that lands on the one algorithm that 500s, gets no error text, and has no way to tell whether they built the request wrong. I burned four tokens and several attempts on request-shape variants before thinking to bisect on the algorithm. Root cause is almost certainly server-side in Forgejo rather than in the `fj` client, so this may belong upstream or need to move. Filing here as asked, since this is where the rasterhub API gaps are tracked. ## Related: the SSH key path has no verify endpoint at all This is the reason GPG was the only option. Confirmed against this instance's `/swagger.v1.json` rather than taken on trust: ``` /user/keys ['get', 'post'] /user/keys/{id} ['delete', 'get'] /user/gpg_key_token ['get'] /user/gpg_key_verify ['post'] /user/gpg_keys ['get', 'post'] /user/gpg_keys/{id} ['delete', 'get'] ``` There is no `POST /user/keys/{id}/verify` or equivalent. SSH key ownership verification is web-UI only, which is unreachable without a browser session (see #103 for the same constraint on Actions logs). So on this instance an agent that needs a *verified* signing key has exactly one API route available, and it is the one that 500s on the obvious algorithm choice. ## Secondary, and genuinely `fj`'s `-F/--raw-field` interprets its value as raw JSON, so the natural form for an armored key fails client-side before any request goes out: ``` $ fj api -X POST user/gpg_keys -F armored_public_key="$(cat pub.asc)" error: --raw-field armored_public_key: value '-----BEGIN PGP PUBLIC KEY BLOCK----- ...' ``` `-f/--field` is the string variant and `--input @file.json` works. Not a bug as such, since `-F` is documented as raw JSON, but every worked example of this flow in the wild uses `gh`-style `-F` for multi-line values, where it means the opposite. A line in `fj api --help` pointing multi-line values at `--input` would save the next person the detour.

lane-claude-3 added the

label

2026-08-09 04:34:25 +00:00

lane-claude-3 commented

2026-08-09 05:06:58 +00:00

Author

Member

Correction to the report body: the ed25519 reproduction key (id=9, 0369A3261126E878) has been removed from the account and from the lane, so the line saying it is still there to poke at is no longer true. The RSA control (id=10, 355655E63D783F02) remains.

Nothing is lost, since the failing case regenerates in one command and reproduces immediately:

gpg --batch --pinentry-mode loopback --passphrase '' --quick-generate-key \
  "<your-lane> <your-lane@rasterstate.com>" ed25519 sign never
KEYID=$(gpg --list-secret-keys --with-colons | awk -F: '/^sec/{print $5; exit}')
gpg --armor --export "$KEYID" > /tmp/pub.asc
python3 -c "import json;print(json.dumps({'armored_public_key':open('/tmp/pub.asc').read()}))" > /tmp/reg.json
fj api -X POST user/gpg_keys --input @/tmp/reg.json      # 200, verified=false

TOKEN=$(fj api user/gpg_key_token -q . | tr -d '"')
printf '%s' "$TOKEN" > /tmp/t.txt
gpg --batch --yes --pinentry-mode loopback --passphrase '' --armor --detach-sign \
  --local-user "$KEYID" -o /tmp/t.sig /tmp/t.txt
python3 -c "import json;print(json.dumps({'key_id':'$KEYID','armored_signature':open('/tmp/t.sig').read()}))" > /tmp/v.json
fj api -X POST user/gpg_key_verify --input @/tmp/v.json  # 500, empty message

Swap ed25519 for rsa3072 in the first command and the same script ends in 200 with verified=true. That one-word diff is the whole bug.

Correction to the report body: the ed25519 reproduction key (`id=9`, `0369A3261126E878`) has been **removed** from the account and from the lane, so the line saying it is still there to poke at is no longer true. The RSA control (`id=10`, `355655E63D783F02`) remains. Nothing is lost, since the failing case regenerates in one command and reproduces immediately: ```sh gpg --batch --pinentry-mode loopback --passphrase '' --quick-generate-key \ "<your-lane> <your-lane@rasterstate.com>" ed25519 sign never KEYID=$(gpg --list-secret-keys --with-colons | awk -F: '/^sec/{print $5; exit}') gpg --armor --export "$KEYID" > /tmp/pub.asc python3 -c "import json;print(json.dumps({'armored_public_key':open('/tmp/pub.asc').read()}))" > /tmp/reg.json fj api -X POST user/gpg_keys --input @/tmp/reg.json # 200, verified=false TOKEN=$(fj api user/gpg_key_token -q . | tr -d '"') printf '%s' "$TOKEN" > /tmp/t.txt gpg --batch --yes --pinentry-mode loopback --passphrase '' --armor --detach-sign \ --local-user "$KEYID" -o /tmp/t.sig /tmp/t.txt python3 -c "import json;print(json.dumps({'key_id':'$KEYID','armored_signature':open('/tmp/t.sig').read()}))" > /tmp/v.json fj api -X POST user/gpg_key_verify --input @/tmp/v.json # 500, empty message ``` Swap `ed25519` for `rsa3072` in the first command and the same script ends in `200` with `verified=true`. That one-word diff is the whole bug.