GPG Signing Displays Incorrectly? #12837

Open
opened 2025-11-02 10:22:30 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @SoulSeekkor on GitHub (Apr 12, 2024).

Description

I updated my GPG key within Gitea yesterday since I had to have no expiration (since it was going to expire in a month, so I removed the expiration). Same key ID, just updated the expiration. The weirdness came when I started looking at my repos, the very last commit (which was with the old expiration) on all the repos are showing as verified but ALL of the rest of the commits after show as suspicious for some reason even though it's the same key used to sign them. Even more strange, is someone else's commits are showing as suspicious who did NOT update their GPG key.

The only other thing I've done was set up in the config a new GPG key on that server locally for use by Gitea when doing pull request merges since all repos now require signed commits. I removed that section though and it made no difference in how this page was showing up.

Gitea Version

1.21.10

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

322122769-efde85cb-e137-40b6-9c1f-69b8ef4cb01c

Git Version

2.42.0

Operating System

Windows Server 2019

How are you running Gitea?

Windows service.

Database

MSSQL

Originally created by @SoulSeekkor on GitHub (Apr 12, 2024). ### Description I updated my GPG key within Gitea yesterday since I had to have no expiration (since it was going to expire in a month, so I removed the expiration). Same key ID, just updated the expiration. The weirdness came when I started looking at my repos, the very last commit (which was with the old expiration) on all the repos are showing as verified but ALL of the rest of the commits after show as suspicious for some reason even though it's the same key used to sign them. Even more strange, is someone else's commits are showing as suspicious who did NOT update their GPG key. The only other thing I've done was set up in the config a new GPG key on that server locally for use by Gitea when doing pull request merges since all repos now require signed commits. I removed that section though and it made no difference in how this page was showing up. ### Gitea Version 1.21.10 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![322122769-efde85cb-e137-40b6-9c1f-69b8ef4cb01c](https://github.com/go-gitea/gitea/assets/16005426/0b4e9a6f-3d29-4441-9aa8-3edf819985d4) ### Git Version 2.42.0 ### Operating System Windows Server 2019 ### How are you running Gitea? Windows service. ### Database MSSQL
GiteaMirror added the topic/commit-signingtype/bug labels 2025-11-02 10:22:30 -06:00
Author
Owner

@SoulSeekkor commented on GitHub (Apr 16, 2024):

So this might not be an issue but I'd like to verify. For these repos I also ripped out LFS, so I think that may have caused the previous commits to be marked as suspicious. Before this gets closed if that is indeed the case, is there any way of rewriting history that doesn't cause that to happen with a signed commit since the changes weren't messed with (I assume no since that's the nature of it). I'd also assume there is no way to have Gitea recognize these as valid commits either instead of suspicious?

@SoulSeekkor commented on GitHub (Apr 16, 2024): So this might not be an issue but I'd like to verify. For these repos I also ripped out LFS, so I think that may have caused the previous commits to be marked as suspicious. Before this gets closed if that is indeed the case, is there any way of rewriting history that doesn't cause that to happen with a signed commit since the changes weren't messed with (I assume no since that's the nature of it). I'd also assume there is no way to have Gitea recognize these as valid commits either instead of suspicious?
Author
Owner

@lunny commented on GitHub (Apr 16, 2024):

Looks like the reason has been ignored for signed commits. Can you hover the mouse on the signing lock to get the reason?

@lunny commented on GitHub (Apr 16, 2024): Looks like the reason has been ignored for signed commits. Can you hover the mouse on the signing lock to get the reason?
Author
Owner

@SoulSeekkor commented on GitHub (Apr 23, 2024):

Yep! The reason is displayed as "WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS."

@SoulSeekkor commented on GitHub (Apr 23, 2024): Yep! The reason is displayed as "WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS."
Author
Owner

@lunny commented on GitHub (Nov 24, 2024):

Yep! The reason is displayed as "WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS."

I think this is because the email of that gpg signing hasn't been activated.

@lunny commented on GitHub (Nov 24, 2024): > Yep! The reason is displayed as "WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS." I think this is because the email of that gpg signing hasn't been activated.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#12837