gitea.com fails to verify ed25519 ggp keys #14534

Open
opened 2025-11-02 11:15:31 -06:00 by GiteaMirror · 5 comments
Owner

Originally created by @bad on GitHub (May 30, 2025).

Description

I'm trying to add and verify my ed25519 gpg key on gitea.com. my user name is "bad".
I've added the following public key block:

$ gpg -a --export DFE41C65BF488407
-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEZ9BP8xYJKwYBBAHaRw8BAQdAm8S9Moj1sWDZ3tPp+8kvEy5YjNHLKFtCCQbN
Z9iWbQC0HUNocmlzdG9waCBCYWR1cmEgPGJhZEBic2QuZGU+iJwEExYKAEQCGwMF
CQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AWIQTNPOD4a/kq85eO00ff
5Bxlv0iEBwUCZ9BQKAIZAQAKCRDf5Bxlv0iEB8NpAQDP3W744EmgQoun5Dt6kiSX
DAe+OBjMrDUbcw5PFwNohwD+MtUGfROWu6TjixlRpkTkU7UnlN0MRrsdlvQMT4kY
0gu4OARn0E/zEgorBgEEAZdVAQUBAQdA8xCeotGJO4Mu96vD8xSW2H/diEp2i36M
lc5mvLn6eVsDAQgHiH4EGBYKACYWIQTNPOD4a/kq85eO00ff5Bxlv0iEBwUCZ9BP
8wIbDAUJBaOagAAKCRDf5Bxlv0iEB9dLAP4pEUyxwIrsEJpp5Qm8JaXwtBB7Gg4Y
JpXYqu2iNU0tRAD/e4oAv6TH0uZfywiUBOk9WhreGhDxy72dNkxe85IfWQk=
=w8Zv
-----END PGP PUBLIC KEY BLOCK-----

and ran the command that gitea tells me to generate the signature for the token:

$ echo "841dafd1ce8ac64c618fa0e63015dfdc0a6acf0ce41633521b90cb22882f2129" | 
    gpg -a --default-key DFE41C65BF488407 --detach-sig
gpg: using "DFE41C65BF488407" as default secret key for signing
-----BEGIN PGP SIGNATURE-----

iHUEABYDAB0WIQTNPOD4a/kq85eO00ff5Bxlv0iEBwUCaDn0/AAKCRDf5Bxlv0iE
BxkHAQCTSja1L9iLLSHFxkd7EjB8somyI1/qhbdqyfiBdbqzWQEAi96+ucn91JL0
TmRiJFIF2dblOFF5pnZRqbGbnoA2Qwg=
=e2NI
-----END PGP SIGNATURE-----

After copying the signature to the corresponding input field and clicking on the "Verify" button
I get at the top of the page:

The provided GPG key, signature and token do not match or token is out-of-date.

None of which is true. I generated the signature within seconds and I can verify the
signature locally with gpg.

Gitea Version

whatever you're running today on gitea.com. it doesn't divulge version or commit hash.

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

I don't. I've used gitea.com.

Database

None

Originally created by @bad on GitHub (May 30, 2025). ### Description I'm trying to add and verify my ed25519 gpg key on gitea.com. my user name is "bad". I've added the following public key block: ``` $ gpg -a --export DFE41C65BF488407 -----BEGIN PGP PUBLIC KEY BLOCK----- mDMEZ9BP8xYJKwYBBAHaRw8BAQdAm8S9Moj1sWDZ3tPp+8kvEy5YjNHLKFtCCQbN Z9iWbQC0HUNocmlzdG9waCBCYWR1cmEgPGJhZEBic2QuZGU+iJwEExYKAEQCGwMF CQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AWIQTNPOD4a/kq85eO00ff 5Bxlv0iEBwUCZ9BQKAIZAQAKCRDf5Bxlv0iEB8NpAQDP3W744EmgQoun5Dt6kiSX DAe+OBjMrDUbcw5PFwNohwD+MtUGfROWu6TjixlRpkTkU7UnlN0MRrsdlvQMT4kY 0gu4OARn0E/zEgorBgEEAZdVAQUBAQdA8xCeotGJO4Mu96vD8xSW2H/diEp2i36M lc5mvLn6eVsDAQgHiH4EGBYKACYWIQTNPOD4a/kq85eO00ff5Bxlv0iEBwUCZ9BP 8wIbDAUJBaOagAAKCRDf5Bxlv0iEB9dLAP4pEUyxwIrsEJpp5Qm8JaXwtBB7Gg4Y JpXYqu2iNU0tRAD/e4oAv6TH0uZfywiUBOk9WhreGhDxy72dNkxe85IfWQk= =w8Zv -----END PGP PUBLIC KEY BLOCK----- ``` and ran the command that gitea tells me to generate the signature for the token: ``` $ echo "841dafd1ce8ac64c618fa0e63015dfdc0a6acf0ce41633521b90cb22882f2129" | gpg -a --default-key DFE41C65BF488407 --detach-sig gpg: using "DFE41C65BF488407" as default secret key for signing -----BEGIN PGP SIGNATURE----- iHUEABYDAB0WIQTNPOD4a/kq85eO00ff5Bxlv0iEBwUCaDn0/AAKCRDf5Bxlv0iE BxkHAQCTSja1L9iLLSHFxkd7EjB8somyI1/qhbdqyfiBdbqzWQEAi96+ucn91JL0 TmRiJFIF2dblOFF5pnZRqbGbnoA2Qwg= =e2NI -----END PGP SIGNATURE----- ``` After copying the signature to the corresponding input field and clicking on the "Verify" button I get at the top of the page: ``` The provided GPG key, signature and token do not match or token is out-of-date. ``` None of which is true. I generated the signature within seconds and I can verify the signature locally with gpg. ### Gitea Version whatever you're running today on gitea.com. it doesn't divulge version or commit hash. ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? I don't. I've used gitea.com. ### Database None
GiteaMirror added the type/bug label 2025-11-02 11:15:31 -06:00
Author
Owner

@badhezi commented on GitHub (Jun 2, 2025):

I am able to add a generated ed25519 gpg key
when i export the public key its longer than yours, i use
gpg --armor --export FB4143B209DA4A76 (use your identifier)

perhaps give that a try

@badhezi commented on GitHub (Jun 2, 2025): I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use `gpg --armor --export FB4143B209DA4A76` (use your identifier) perhaps give that a try
Author
Owner

@bad commented on GitHub (Jun 2, 2025):

I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use gpg --armor --export FB4143B209DA4A76 (use your identifier)

perhaps give that a try

Excuse me? "-a" is shorthand for "--armor". That's obvious from the man page.
Natuarlly, using "--armor" instead of "-a" produces the exact same output.

@bad commented on GitHub (Jun 2, 2025): > I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use `gpg --armor --export FB4143B209DA4A76` (use your identifier) > > perhaps give that a try Excuse me? "-a" is shorthand for "--armor". That's obvious from the man page. Natuarlly, using "--armor" instead of "-a" produces the exact same output.
Author
Owner

@badhezi commented on GitHub (Jun 2, 2025):

I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use gpg --armor --export FB4143B209DA4A76 (use your identifier)
perhaps give that a try

Excuse me? "-a" is shorthand for "--armor". That's obvious from the man page. Natuarlly, using "--armor" instead of "-a" produces the exact same output.

I'm definitely not a pro on gpg but I managed to add a ed25519 key, perhaps you can share to command you used to generate the key and we will try to reproduce the issue.

@badhezi commented on GitHub (Jun 2, 2025): > > I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use `gpg --armor --export FB4143B209DA4A76` (use your identifier) > > perhaps give that a try > > Excuse me? "-a" is shorthand for "--armor". That's obvious from the man page. Natuarlly, using "--armor" instead of "-a" produces the exact same output. I'm definitely not a pro on gpg but I managed to add a ed25519 key, perhaps you can share to command you used to generate the key and we will try to reproduce the issue.
Author
Owner

@bad commented on GitHub (Jun 2, 2025):

I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use gpg --armor --export FB4143B209DA4A76 (use your identifier)
perhaps give that a try

Excuse me? "-a" is shorthand for "--armor". That's obvious from the man page. Natuarlly, using "--armor" instead of "-a" produces the exact same output.

I'm definitely not a pro on gpg but I managed to add a ed25519 key, perhaps you can share to command you used to generate the key and we will try to reproduce the issue.

You don't need to be a pro. You don't even need to read the manual. All you had todo was to run both versions of the command and compare the output to see if your suggestion had any merit at all before sending people on a wild goose chase. You can compare two files, can you?

I can't share the command to produce the key because I can't remember it and I didn't log the interactive session. I can tell you that, apart from requestion an ed25519 key and a different life time, I used the default answers to gpg's questions.

However, you don't need to know how the key was produced. You have all the information that gitea requests to verify the key: the public key, the token, and the signature.
What you do need to do is to produce diagnostic output from gitea when it tries to verify the signature. If you are able to produce the actual gpg invocation used to verify the signature then I am, maybe, able to help you, provided that I can then reproduce the problem locally.

I'm extremely busy at the moment. Even if you provide the actual gpg invocation and the diagnostics, I'm not able to spend more time on this until the second half of June.
However, if you cannot ascertain me that you actually have the expertise, means, and perhaps privileges, to produce said data I'm not going to converse with you any further.

@bad commented on GitHub (Jun 2, 2025): > > > I am able to add a generated ed25519 gpg key when i export the public key its longer than yours, i use `gpg --armor --export FB4143B209DA4A76` (use your identifier) > > > perhaps give that a try > > > > > > Excuse me? "-a" is shorthand for "--armor". That's obvious from the man page. Natuarlly, using "--armor" instead of "-a" produces the exact same output. > > I'm definitely not a pro on gpg but I managed to add a ed25519 key, perhaps you can share to command you used to generate the key and we will try to reproduce the issue. You don't need to be a pro. You don't even need to read the manual. All you had todo was to run both versions of the command and compare the output to see if your suggestion had any merit at all before sending people on a wild goose chase. You can compare two files, can you? I can't share the command to produce the key because I can't remember it and I didn't log the interactive session. I can tell you that, apart from requestion an ed25519 key and a different life time, I used the default answers to gpg's questions. However, you don't need to know how the key was produced. You have all the information that gitea requests to verify the key: the public key, the token, and the signature. What you _do_ need to do is to produce diagnostic output from gitea when it tries to verify the signature. If you are able to produce the actual gpg invocation used to verify the signature then I am, maybe, able to help you, provided that I can then reproduce the problem locally. I'm extremely busy at the moment. Even if you provide the actual gpg invocation and the diagnostics, I'm not able to spend more time on this until the second half of June. However, if you cannot ascertain me that you actually have the expertise, means, and perhaps privileges, to produce said data I'm not going to converse with you any further.
Author
Owner

@imdn commented on GitHub (Aug 13, 2025):

I can confirm that I have the same problem with ed25519 gpg keys on self-hosted Gitea.

Gitea Version: 1.24.4

The key was generated on Linux, so it does not seem to have anything to do with the OS as other issues having to do with GPG keys seem to suggest. Attaching screenshot below.

Curiously, I was able to add the first ed25519 key for an alternate id I sometimes use (after repeated attempts). It was when adding the second key with the same algorithm (ed25519) that I faced this issue.

I'm quite positive I haven't mixed up the keys. The suggestion suggested by @badhezi above, to use the long keyid format, didn't help either.

Image
@imdn commented on GitHub (Aug 13, 2025): I can confirm that I have the same problem with ed25519 gpg keys on self-hosted Gitea. **Gitea Version**: 1.24.4 The key was generated on Linux, so it does not seem to have anything to do with the OS as other issues having to do with GPG keys seem to suggest. Attaching screenshot below. Curiously, I was able to add the first ed25519 key for an alternate id I sometimes use (after repeated attempts). It was when adding the second key with the same algorithm (ed25519) that I faced this issue. I'm quite positive I haven't mixed up the keys. The suggestion suggested by @badhezi above, to use the long keyid format, didn't help either. <img width="1301" height="1458" alt="Image" src="https://github.com/user-attachments/assets/78f2897b-84e0-47c0-8381-e17377e60c0c" />
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14534