Gitea: Instance GPG key not recognized if subkey

[cleverer]

• Gitea version (or commit ref): 1.11.0
• Git version: 2.17.2
• Operating system: macOS 10.13.6 (17G11023)
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [x] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [x] No
  
  
  • [ ] Not relevant
  
  
• Log gist:

Description

Regarding the new signing functionality introduced in #7631

Gitea only checks for the primary key when checking a commit with gpgSettings:
https://github.com/go-gitea/gitea/blob/master/models/gpg_key.go#L738-L742
If one uses a subkey to sign, this doesn't get recognized in the GUI.

Screenshots

[lunny]

@cleverer Could you confirm the old gitea version worked?

[cleverer]

That wouldn't make sense, as the possibility of signed merge commits, repository creations etc. was only introduced in 1.11.0.

I'm not talking about a manually signed commit but a commit automatically created and signed from the GUI.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[cleverer]

Bad bot. Could a member please reopen this?

Is there anything I can do to help get this resolved?

[b90g]

I use subkeys successfully but had issues at the beginning, i had to add the email address of the gpg key also to the account and verify it.

[zeripath]

@b90g can you put an example up on try.gitea.io?

[zeripath]

(I'm currently working on GPG verification again - so if I can get an example I can get this fixed and backported in to 1.12 PDQ.)

[b90g]

https://try.gitea.io/klaus/lhmmm/commit/25752a80e3913e1a04a42e140016f79d40d6766e

[email protected]
Key ID: REDACTEDHASH Subkeys: REDACTEDHASH REDCATEDHASH
Added on May 30, 2020 - Valid forever 

feel free to request more interaction (altough a lot of requests fail torwards try.gitea.io from bad gateway to 404..)

Its a completly stripped subkey. ( https://wiki.debian.org/Subkeys )

[cleverer]

To clarify, regular git commits signed with a subkey work just fine. However you can set up Gitea so it signs commits done on the web (eg. when merging or creating a new repo).

If you configure your gitea with a subkey the verification fails. If you pull that repository and check locally with the correct public key, everything is fine.

I think the problem lies somewhere here. I think the parsing of the key doesn't work with subkeys somehow. However I'm not too familiar with Go, so I might be wrong…

[zeripath]

Hi!

So that appears to be matching and verifying fine on try

[zeripath]

@cleverer could you give me the commands used to create the subkey so I can try to repeat your problem?

[zeripath]

Ah figured it out!

[cleverer]

👍 Let me know if you still need the instructions or some help in other form! (I think I originally created the subkeys in GPG Keychain for mac, so not sure about the specific commands right now).

11713 looks very promising though!

[zeripath]

If you could have a go with it and confirm it fixes your issue that would be good

[cleverer]

I can try to get the PR running tomorrow, but I can't promise anything, I haven't set up a gitea dev-environment and am not really familiar with Go (yet).

Thanks a lot for your effort though!

[cleverer]

I can confirm, it works like a charm! Thanks a lot!