Documentation
¶
Overview ¶
gitea-signing-debug drives the full SSH-signed-commit flow against a live Gitea and reports Gitea's commit verification verdict at every stage.
The goal is to isolate *which* step in the dance flips Gitea from `verified=false, reason=gpg.error.no_gpg_keys_found, signer=null` to a verified commit. The hypothesis this tool encodes: admin-uploaded SSH keys start with public_key.verified=false, and Gitea will refuse to use them for commit-signature verification until the key owner proves possession by signing a per-user token and POSTing it to /user/keys/verify.
Flow:
- Create (or rotate) a per-run Gitea user with a known password.
- Create a repo owned by that user.
- Generate an SSH signing keypair; upload the public half via admin.
- Query commit verification BEFORE key verification (expected: fail). (Actually: we make the commit first, then query both pre- and post-verify.)
- Prepare a local git clone, make an SSH-signed commit authored with the user's email, and push it over HTTPS.
- Query commit verification BEFORE /user/keys/verify (expected: fail with `no_gpg_keys_found`).
- Sign the Gitea-issued token with `ssh-keygen -Y sign -n gitea` and POST it to /user/keys/verify AS THE USER.
- Re-query the key and commit verification (expected: verified=true).
Usage:
go run ./cmd/gitea-signing-debug \ --gitea-url http://localhost:13000/api/v1 \ --admin-user giteaadmin --admin-pass giteapassword123
Click to show internal directories.
Click to hide internal directories.