GPG not using correct UID

[crabctrl]

• Gitea version (or commit ref): 1.7.0
• Git version: 2.21.0
• Operating system: Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes
  • No
  • Not relevant

Description

My GPG key has a revoked UID attached to it (it was revoked since I no longer own the email address it refers to). My primary UID is valid, and the email address it points to has been added to my Gitea account. However, when trying to add my key, Gitea displays the old (revoked) UID as the primary, and any commits signed using the updated key are marked as No known key. I tried removing my old email address from my account, and now Gitea just says my I need to have my old address attached in order to load the key.

It seem that Gitea is not correctly loading the primary UID. In addition, the commits should still be verified even with the updated key; it should be loading all UIDs ideally. Any help would be greatly appreciated.

[lafriks]

Can you give your public gpg key that is problematic?

[crabctrl]

My key fingerprint is 0E72F749E5D4E92F1F1D5F2BCDAD63AE9DA934BE, the actual key is:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEXHmwNRYJKwYBBAHaRw8BAQdADJQJlOscbuBH+CyJC9GVm3kKBD0Az8Ew7yqy
MzQgwDm0KUFsZGVuIFBlZXRlcnMgPGFsZGVuLnBlZXRlcnNAbGVhZ3VlaC54eXo+
iJkEExYIAEECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4ACGQEWIQQOcvdJ5dTp
Lx8dXyvNrWOunak0vgUCXMMqvAUJAkujhwAKCRDNrWOunak0vn92AQDmkeyYEmlx
cHrnnCJAHub3aq0/M960vqYKX+mpgXuapwD+LEEdQ1LDg+hmzaNsgF+JRI/GeRE+
NpH02rJydqnPmgOIjwQTFggAOBYhBA5y90nl1OkvHx1fK82tY66dqTS+BQJcwhFN
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEM2tY66dqTS+508A+MZsy+wH
LD5gzke8keuZtsQwE4181PUN2YKr0pPQcJIBALHD2DIa0Zq91NiFRUq7wc8Bogsu
8ya4cjUZPf9RcdUBtCZBbGRlbiBQZWV0ZXJzIDxhbGRlbkBvcGVuZm9ydHJlc3Mu
eHl6PoiYBDAWCABAFiEEDnL3SeXU6S8fHV8rza1jrp2pNL4FAlzCEWUiHSBObyBs
b25nZXIgb3duIHRoaXMgZW1haWwgYWRkcmVzcwAKCRDNrWOunak0vsBhAP9ZxNlQ
q4ibb04LxQIwijK9brNge8Jqu2LInmcs0VXa9QD+JdkhYtRcFLXDyQi03uuAUa4y
hTYQvgeqP9EBllNbCwSIkAQTFggAOBYhBA5y90nl1OkvHx1fK82tY66dqTS+BQJc
ebA1AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEM2tY66dqTS+Rq4A/Az/
HkAVEFaIVR/E/IyfWpp30jhmior9iorrwR5zJcIXAQCqPRG7bKSv4t0M25z7MzGe
z4A8ru/O/2BWGbz3DwFoDrg4BFx5sDUSCisGAQQBl1UBBQEBB0C6aNJqaSPLAVVg
puuvK645awUD42NBnO863AVf23aXOgMBCAeIfgQYFggAJgIbDBYhBA5y90nl1Okv
Hx1fK82tY66dqTS+BQJcwyr7BQkCS6PGAAoJEM2tY66dqTS+J24BAJQE59jBQFwH
OYRCigOJJVsWWNs35TilZ1xaxs8mnDjHAQDo18Q/Uw1zBPH2Mr5LRAbQwnwoVwgU
FkzJRllII58iAA==
=SS9a
-----END PGP PUBLIC KEY BLOCK-----

[sapk]

Looking at your public key, the old UID is still the primary UID. It would need to check what identities is returned in from this keys where we search for matching emails.

gitea/models/gpg_key.go

Line 276 in e83dddb

for _, ident := range e.Identities {

[sapk]

I added a test to debug, and I seems to get both emails listed so it should match at least your new email. I need to look further to find the mismatch.

[sapk]

Maybe we should update the lib: keybase/go-crypto@2c2b831#diff-e7ace1eeeac9cdf4f5fe331bf53e3fb2

[xf-]

I use also multiple mail addresses in my key and commit with different once (work, private...).
@sapk you only look into loading issue of primary and not to load all UIDs or?

[sapk]

@xf- We load all identities that are linked to the key. The problem here is that an identities is revoked in the key export and the lib we use still list it as a good identities. In fact if I recall well my testing, it doesn't even match/return the revocation.

[xf-]

@sapk deleted the key and imported it again. Now it works! THX

[crabctrl]

Is something still needed from me? (I only ask because of the label)

[sapk]

@atoms118 No we have enough to reproduce (added as a test in #6794), To be fixed we would need to fix it in the lib we use that seems to list the identities of the revoked uid when it shouldn't (but doesn't list revoked uid for the key listed in there tests 😕). I haven't look futhermore.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[sapk]

This issue need to be kept open.

[zeripath]

I am suspicious that this might have been resolved by #12155

[zeripath]

OK I'm not certain completely what's going on here.

There's likely a part of this issue which has been resolved by #12155 (which affects subkey verifcation.)

Another part is likely fixed by @techknowlogick's recent PR removing the email address reporting on a commit - (so not necessarily fixed but masked).

Now there is the question about whether we should be verifying against a revoked identity, and #12486 stops that but... I think we need to double check against what GH does for revoked IDs. There's an issue with the way GH uses git signatures here - it uses them as committer verification and therefore a signature matching a revoked email address is not necessarily incorrect.

There is a final potential issue that I can see:

When you are posting your keys are you pasting multiple keys on a single keyring? Because Gitea isn't currently set up to do - it would be possible to cope with that but it's not doing that at present.