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
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • 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]

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]

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

REDACTED@REDACTED.TDL
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…