Signed commits on gitea.com fail to verify

dachary · October 16, 2021, 7:02pm

Bonjour,

This pull request shows a signed commit tagged as suspicious.

However, when I verify it manually, it checks out:

$ git verify-commit 9eee365e33
gpg: Signature made sam. 16 oct. 2021 08:50:47 -10
gpg:                using RSA key E99FFE83DF73E72FB6B264ED992D23B392F9E4F2
gpg: Good signature from "Loic Dachary (OuoU) <loic@gnu.org>" [ultimate]
gpg:                 aka "Loic Dachary (OuoU) <loic@dachary.org>" [ultimate]
gpg:                 aka "Loic Dachary (OuoU) <loic@debian.org>" [ultimate]

and the corresponding GPG public key is set correctly in the preferences.

Am I doing something wrong?

techknowlogick · October 17, 2021, 12:32am

I believe it is due to the “trust model” of that specific repo (as you are not a member of the org, it may see your signature as suspicious). If you look at that same commit, but under your fork it should verify as valid.

dachary · October 17, 2021, 2:32am

It is also considered to be suspicious in my own repository

dachary · October 17, 2021, 2:57pm

For the record @lunny tried to change the Signing Verification Settings for the repository but the commit signature is still considered suspicious.

I also tried to change the setting as follows and push another signed commit but commit signature is still considered suspicious.

techknowlogick · October 17, 2021, 9:41pm

that’s uhh… not good.

Let me poke around at it a bit and see what I figure out.

dachary · November 29, 2021, 7:17am

The email associated with the key was not verified (thanks @zeripath for suggesting that might be the source of the problem).

After validating the email, I removed the GPG key, added it again, pushed a branch with a signed commit and it’s all good. Mystery solved

zeripath · November 29, 2021, 9:10am

Yeah we can’t safely verify a commit against an unvalidated/unactivated email address - otherwise someone could easily spoof identities. We need to confirm that you have the email address you’re purporting to sign for.

The slight gotcha here is that instead of storing all of the addresses that a key has we only store the ones that are activated at the time of addition meaning that if you add a key and then later activate an address you have to re-add the key or sign a token with the key (thus confirming you have the key) allowing it to match any of the activated addresses we have for you. (Likely we should just store all of the keys and match activated ones at the time of verification but I’ve not had the chance to do that.)