Page MenuHome GnuPG

Add mailmap feature to GnuPG for GDPR compliance
Closed, WontfixPublic


Today's situation of OpenPGP is a dim situation. There is lack of exposure and the keyservers infrastructure is going all insecure, with the new standard way of only needing a email link to remove a key from the keyserver. Instead of making use of revocation certificates.
This is due to the rise of Hockeypuck keyservers and the fall of SKS keyservers, due to GDPR EU law reasons.

I, myself, dislike this route that is being traced, and want to make SKS keyservers the most prominent keyserver again, because it relies on revocation certificates, instead of email links, for key "invalidation". But the EU's GDPR claims are valid and must be fulfilled in today's age.

I am thinking about this scenery, and I think I have got the solution, that may make OpenPGP keyservers infrastructure secure again... and this solution requires a feature in GnuPG (and any OpenPGP client). This solution is similar to "why doesn't Microsoft Github gets sued by GDPR complains of git's personal info hosting".
It is all about the git's mailmap file feature, and I basically want GnuPG to also have a mailmap file feature. So that keyservers may easily "remove" (or disconnect) personal info (email, name and photo) from the GDPR offended user key in the GnuPG keyserver keyring.

So basically GnuPG could have a mailmap file and any entry of this file makes GnuPG "substitute" the corresponding key personal info (email, name and photo) with the info in the mailmap's corresponding entry. This substitution can be made on GnuPG key listing output. This idea is similar of git's mailmap ->

It could go even further and make a option, related to this mailmap feature, where any key personal info (name and email and photo) imported, would be substituted by default by a stub (such as user0000001,, and a anonymous default photo), and, in the mailmap file, a entry of the real personal info would be added automatically. So, this way, if a user wants to delete it's data from the keyserver, the keyserver admin would only delete this user entry on the mailmap file (and would also need to remove the user photo file), leaving no trace of this user personal data on the keyserver's files. An command, or option, can be made for automatic removal of the mailmap's entry and the corresponding photo, to ease up keyserver's sysadmin job.

I hope that I am making this idea clear enough, but if you need any further understanding, I will happily try to clear any doubts in this thread. This feature idea is basically taken away from Git's mailmap feature (the link is above, where you can read more).



Event Timeline

danisanti updated the task description. (Show Details)
danisanti updated the task description. (Show Details)
danisanti renamed this task from Add mailmap feature to GnuPG to Add mailmap feature to GnuPG for GDPR compliance.Mar 16 2023, 1:59 PM
danisanti updated the task description. (Show Details)

A tool can't make some thing GDPR compliant - this is all about policy and informed choice. There is actually no problem if you allow ppl to decide whether to upload personal information to a public service.

My suggestion for keyservers is:

  • Don't allow searching by userid
  • Provide retrieval by fingerprint only.

My suggestions for GUI is:

  • get consent from the user before uploading a key.
  • Upload only those user ids with just a mail address.

Werner, according to GDPR if a user upload a key with it's name and email address he or she may be able in the future, to ask for removal of this information.
How is this going to happen, to a keyserver, accordingly to your suggestions?

This GDPR removal right is what made problem with the SKS keyservers that used to be online. These are now offline because of the law.

werner claimed this task.

Not if there are technical reasons to keep the address. BTW, you solution would not help because the fingerprint of key is personal data in the same way as a mail address.

Please take such discussions to a mailing list - a bug tracker is not the right place.