GPG keys with revoked email addresses cannot be verified #917

Closed
opened 2025-11-02 03:41:24 -06:00 by GiteaMirror · 10 comments
Owner

Originally created by @mxmehl on GitHub (Jul 25, 2017).

  • Gitea version (or commit ref): dde0052
  • Git version: 2.1.4
  • Operating system: Debian 8
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant

Description

Users cannot add their GPG keys if it contains a revoked email address/UID. Gitea requires them to verify this email address although it's revoked and possible not accessible anymore.

This bug was reported by a user of git.fsfe.org. His key is 0x8018F380D795A951, and the @fastmail.fm UID is revoked.

Originally created by @mxmehl on GitHub (Jul 25, 2017). - Gitea version (or commit ref): dde0052 - Git version: 2.1.4 - Operating system: Debian 8 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description Users cannot add their GPG keys if it contains a revoked email address/UID. Gitea requires them to verify this email address although it's revoked and possible not accessible anymore. This bug was reported by a user of git.fsfe.org. His key is [0x8018F380D795A951](http://http-keys.gnupg.net/pks/lookup?op=vindex&search=0x8018F380D795A951), and the @fastmail.fm UID is revoked.
GiteaMirror added the lgtm/need 2type/bug labels 2025-11-02 03:41:24 -06:00
Author
Owner

@sapk commented on GitHub (Jul 25, 2017):

Don't know how github handle thoses corner cases.

@sapk commented on GitHub (Jul 25, 2017): Don't know how github handle thoses corner cases.
Author
Owner

@mxmehl commented on GitHub (Jul 25, 2017):

Am 25.07.2017 um 14:54 schrieb Antoine GIRARD:

Don't know how github handle thoses corner cases.

AFAIK, Github doesn't even verify all email addresses which is bad from
the security perspective. I think there's another recent GPG issue here
where this has been elaborated (cannot access the issues right now).

@mxmehl commented on GitHub (Jul 25, 2017): Am 25.07.2017 um 14:54 schrieb Antoine GIRARD: > Don't know how github handle thoses corner cases. AFAIK, Github doesn't even verify all email addresses which is bad from the security perspective. I think there's another recent GPG issue here where this has been elaborated (cannot access the issues right now).
Author
Owner

@lafriks commented on GitHub (Jul 25, 2017):

@sapk in GPG public key there is info that this email has been revoked so they just need to be ignored

@lafriks commented on GitHub (Jul 25, 2017): @sapk in GPG public key there is info that this email has been revoked so they just need to be ignored
Author
Owner

@sapk commented on GitHub (Jul 25, 2017):

I will try to setup a repo to view how others solutions handler thoses corners.
More generaly, GPG capabality needs to be more tested especially for corner cases. If you have more example, it would be really helpfull to write some test. I will take time to implement the fixes.

@sapk commented on GitHub (Jul 25, 2017): I will try to setup a repo to view how others solutions handler thoses corners. More generaly, GPG capabality needs to be more tested especially for corner cases. If you have more example, it would be really helpfull to write some test. I will take time to implement the fixes.
Author
Owner

@mxmehl commented on GitHub (Jul 28, 2017):

I don't know about many corner cases Gitea would have to take care of:

  • Gitea should ignore verification of revoked email UIDs
  • What does Gitea do if a GPG key expires? Does it even accept expired GPG keys?
@mxmehl commented on GitHub (Jul 28, 2017): I don't know about many corner cases Gitea would have to take care of: - Gitea should ignore verification of revoked email UIDs - What does Gitea do if a GPG key expires? Does it even accept expired GPG keys?
Author
Owner

@sapk commented on GitHub (Jul 28, 2017):

Most of the checkup at import is done here : 1721cf474e/models/gpg_key.go (L178)

  • Totally ok, this should be modify here and check Signatures
  • So a expired key could be imported and the VerifySignature used to check commit sign doesn't seems to check up expiration time of key it rely on Verify method of each algo. I will need to add the checkup that the commit is in the period of validity of the key but we should keep being able to import old key for history.
@sapk commented on GitHub (Jul 28, 2017): Most of the checkup at import is done here : https://github.com/sapk-fork/gitea/blob/1721cf474e23675be714cc59593b74cb2a6c1682/models/gpg_key.go#L178 - Totally ok, this should be modify [here](https://github.com/sapk-fork/gitea/blob/1721cf474e23675be714cc59593b74cb2a6c1682/models/gpg_key.go#L213) and check [Signatures](https://godoc.org/golang.org/x/crypto/openpgp#Identity) - So a expired key could be imported and the [VerifySignature](https://godoc.org/golang.org/x/crypto/openpgp/packet#PublicKey.VerifySignature) used to check commit sign doesn't seems to check up expiration time of key it rely on [Verify](https://godoc.org/crypto/ecdsa#Verify) method of each algo. I will need to add the checkup that the commit is in the period of validity of the key but we should keep being able to import old key for history.
Author
Owner

@bkcsoft commented on GitHub (Aug 24, 2017):

GitLab just added GPG verification in 9.5. It only allows you to add GPG-keys which has a registered and valid email, and the GPG key has to be valid (not expired).

@bkcsoft commented on GitHub (Aug 24, 2017): GitLab just added GPG verification in 9.5. It only allows you to add GPG-keys which has a registered and valid email, and the GPG key has to be valid (not expired).
Author
Owner

@sapk commented on GitHub (Aug 24, 2017):

The problem here is that you can have multiple email attached to one gpg key. We you could have one valid email and other not. We just need to validate commit only for valid email one.

@sapk commented on GitHub (Aug 24, 2017): The problem here is that you can have multiple email attached to one gpg key. We you could have one valid email and other not. We just need to validate commit only for valid email one.
Author
Owner

@mxmehl commented on GitHub (Aug 24, 2017):

We just need to validate commit only for valid email one.

That, and Gitea also has to deal with revoked email addresses (which is different from expired).

@mxmehl commented on GitHub (Aug 24, 2017): > We just need to validate commit only for valid email one. That, and Gitea also has to deal with revoked email addresses (which is different from expired).
Author
Owner

@sapk commented on GitHub (Aug 24, 2017):

I rely on on IsActivated for using the key/email combinaison and VerifySignature of opengpg lib to validate the hash. With #2266 you should be able to add a gpg key a revoked email (just need at least another one valid) and only the valid email could be sign.

I added integration test in PR but not for revoked key. I add later in another PR to don't have regression but this should work.

@sapk commented on GitHub (Aug 24, 2017): I rely on on IsActivated for using the key/email combinaison and VerifySignature of opengpg lib to validate the hash. With #2266 you should be able to add a gpg key a revoked email (just need at least another one valid) and only the valid email could be sign. I added integration test in PR but not for revoked key. I add later in another PR to don't have regression but this should work.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#917