gh parity: no first-class gpg-key command — adding a key to the account means hand-building JSON for the raw api passthrough #53

New issue

Closed

opened 2026-07-13 21:38:24 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-13 21:38:24 +00:00

(Migrated from codeberg.org)

Adding the release-signing public key to a forge account had no first-class path. The actual workflow was:

gpg --armor --export <keyid> to a file,
hand-escape the 43-line armored block into a JSON string ({"armored_public_key": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n..."}),
madt_api_call POST /user/gpg_keys,
…which failed with token does not have at least one of required scope(s): [write:user] — a clear error, but only surfaced after all the manual assembly.

gh ships gh gpg-key add <key-file> / list / delete (and the ssh-key sibling). Per the naming conventions (ADR 0016, gh verbatim), madtea should too:

madtea gpg-key add [<key-file>] — read the armored key from a file or stdin, wrap the JSON, POST /user/gpg_keys; list / delete <id> on the same noun. Consider the ssh-key sibling while in there (madtea already has auth use-ssh, so ssh-key add has an existing consumer).
MCP surface per the one-noun-one-tool convention (likely on the users domain).
endpointSuggestions entries for /user/gpg_keys (and /user/keys) pointing at the new command.
A scope preflight would be a nice touch: auth whoami already reports token scopes — the new command could name the missing write:user scope before asking the server, the way the raw call only did at the end.
New command ⇒ docs/COMPARISON.md rows (gh has both key commands; tea/fj coverage varies).

Observed on codeberg.org (Forgejo) 2026-07-13 while adding the madtea release-signing pubkey to my account.

Adding the release-signing public key to a forge account had no first-class path. The actual workflow was: 1. `gpg --armor --export <keyid>` to a file, 2. hand-escape the 43-line armored block into a JSON string (`{"armored_public_key": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n..."}`), 3. `madt_api_call POST /user/gpg_keys`, 4. …which failed with `token does not have at least one of required scope(s): [write:user]` — a clear error, but only surfaced after all the manual assembly. gh ships `gh gpg-key add <key-file>` / `list` / `delete` (and the `ssh-key` sibling). Per the naming conventions (ADR 0016, gh verbatim), madtea should too: - `madtea gpg-key add [<key-file>]` — read the armored key from a file or stdin, wrap the JSON, POST `/user/gpg_keys`; `list` / `delete <id>` on the same noun. Consider the `ssh-key` sibling while in there (madtea already has `auth use-ssh`, so ssh-key add has an existing consumer). - MCP surface per the one-noun-one-tool convention (likely on the users domain). - `endpointSuggestions` entries for `/user/gpg_keys` (and `/user/keys`) pointing at the new command. - A scope preflight would be a nice touch: `auth whoami` already reports token scopes — the new command could name the missing `write:user` scope *before* asking the server, the way the raw call only did at the end. - New command ⇒ `docs/COMPARISON.md` rows (gh has both key commands; tea/fj coverage varies). Observed on codeberg.org (Forgejo) 2026-07-13 while adding the madtea release-signing pubkey to my account.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#53

No description provided.

Rows
Columns