The gpg commiter of the initial commit behaves weird

[jueti]

🥧

• Gitea version (or commit ref): 1.11.6+2-g5d4251eb7 (06/09/2020 06:51:55)
• Git version: 2.20.1-2+deb10u3
• Operating system: Debian GNU/Linux 10 (buster) (10.4)
• Database: PostgreSQL 12+215.pgdg100+1
• Can you reproduce the bug at https://try.gitea.io: No
• Log gist:

Description

I have transfered my workflow to gitea for a short time. I realize that gitea is suitable for a portable code manage platform on Raspberry 4B as a permanent service. Therefore, it's essencial for me to show gpg signature of commits.

I flow the user guide step by step: GPG Commit Signatures.

Firstly, I generated gpg key for my raspi.
Then, I import secret-subkey and set password to null.
Next, I change relavant configurations in /home/git/.gitconfig and /etc/gitea/app.ini.
Finally, I restart the gitea services and copy public key to admin user named gitea.

At the beginning, I create a repo as gitea and everything goes well.

I'm so excite but tragedy cames one after another.

I create a normal user name jueti and add my own gpg public keys. Then, I create a repo but a warning was occured:

WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS.

So I tried to use git log command to see what was happened, and I found an unusal result.

compare to an initial commit of Github.

So it's obvious that the initial commit of jueti/test should be committed by gitea <gitea@raspi-4b.local instead of jueti <jasonyang@stu2016.jnu.edu.cn>.

So it's obvious that the commiter of the initial commit should be gitea <gitea@raspi-4b.local.

Configurations

/home/git/.gitconfig

[user]
        name = gitea
        email = gitea@raspi-4b.local
        signingkey = C5A84090
[commit]
        gpgsign = true
[gpg]
        program = /usr/bin/gpg
[core]
        quotepath = false
        commitGraph = true
[gc]
        writeCommitGraph = true

/etc/gitea/app.ini

[repository.signing]
SIGNING_KEY    = C5A84090
SIGNING_NAME   = gitea
SIGNING_EMAIL  = gitea@raspi-4b.local
INITIAL_COMMIT = always
CRUD_ACTIONS   = pubkey, twofa, parentsigned
WIKI           = pubkey, twofa, parentsigned
MERGES         = pubkey, twofa, basesigned, commitssigned

gpg -K --keyid-format short

/home/git/.gnupg/pubring.kbx
----------------------------
sec#  rsa4096/BE6A1CD3 2020-06-14 [C]
      0916836C9F9B437341DAD5A1B8C833ECBE6A1CD3
uid         [ultimate] gitea <gitea@raspi-4b.local>
ssb   ed25519/C5A84090 2020-06-14 [S] [expires: 2023-06-14]
ssb   ed25519/50E06E86 2020-06-14 [A] [expires: 2023-06-14]
ssb   cv25519/19D7986D 2020-06-14 [E] [expires: 2023-06-14]

[zeripath]

First of all let me disabuse of the notion that the Committer has to be the Signer.

There is no such requirement in Git and git verify-commit will simply check if the signature matches a key in your keyring and report which key did so.

Github has decided that it will use Signatures to verify Committer but that is their decision and Gitea does not require that: This is why Gitea always shows the avatar and information of the Signer separate from the Committer. It is a different Trust model to Github - one which allows you to re-sign commits following revocation of keys or as part of a fully signed tree with one key without loss of committer information - (albeit with change of SHAs)

There is a PR which will allow users to use the Github style of committer-verification but it is not merged as yet.

However, there is clearly a problem if you have a commit that should verify as per git verify-commit but it does not verify on Gitea.

I believe that #11713 and its backport to 1.12 #11747 should fix this - so if it is at all possible I would ask you to test this with the latest 1.12 rc or master and report back if that works - if it does I can send a backport to 1.11 to get that fix in.

[jueti]

I'm agree with you. My expression is unclear so I change it slightly.

I'm plesured to migrate to 1.12 rc and it's not troublesome.

Thanks for your work. 🎉

[jueti]

• Gitea version (or commit ref): 1.12.0-rc2 (06/08/2020 08:04:54)
• Git version: 2.20.1-2+deb10u3
• Operating system: Debian GNU/Linux 10 (buster) (10.4)
• Raspi model: Raspberry Pi 4 Model B Rev 1.4
• Database: PostgreSQL 12+215.pgdg100+1
• Can you reproduce the bug at https://try.gitea.io: No
• Log gist:
• /etc/gitea/app.ini

[repository.signing]
SIGNING_KEY    = C5A84090
SIGNING_NAME   = gitea
SIGNING_EMAIL  = gitea@raspi-4b.local
INITIAL_COMMIT = always
CRUD_ACTIONS   = pubkey, twofa, parentsigned
WIKI           = pubkey, twofa, parentsigned
MERGES         = pubkey, twofa, basesigned, commitssigned

• ~/.gitconfig

[user]
        name = gitea
        email = gitea@raspi-4b.local
        signingkey = C5A84090
[commit]
        gpgsign = true
[gpg]
        program = /usr/bin/gpg
[core]
        quotepath = false
        commitGraph = true
[gc]
        writeCommitGraph = true

• gpg -K --keyid-format short

/home/git/.gnupg/pubring.kbx
----------------------------
sec#  rsa4096/BE6A1CD3 2020-06-14 [C]
      0916836C9F9B437341DAD5A1B8C833ECBE6A1CD3
uid         [ultimate] gitea <gitea@raspi-4b.local>
ssb   ed25519/C5A84090 2020-06-14 [S] [expires: 2023-06-14]
ssb   ed25519/50E06E86 2020-06-14 [A] [expires: 2023-06-14]
ssb   cv25519/19D7986D 2020-06-14 [E] [expires: 2023-06-14]

Everything goes well as you said.