Organizations with an internal LDAP server will benefit from an auto-upload after key generation. Maybe we can have a value for the option to extend it to also upload modifications. Or should we always upload modifications?
Description
Revisions and Commits
rG GnuPG | |||
rG152e02bd87bb gpg: Make --auto-upload also work for the --quick commands. | |||
rGf64a456271dd gpg: Make --auto-upload also work for --edit-key | |||
rG48e5282c86c2 gpg: New option --auto-key-upload |
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T6713 Kleopatra or GPG: Configuration to auto publish key changes | ||
Open | • werner | T7333 Allow gpg to auto-upload a new own key to LDAP servers |
Event Timeline
I suggest always updating modifications which are "exportable".
In case the option is set but no LDAP server is defined, the option is ignored and a warning is displayed.
In case the LDAP server is not reachable, an error message should be shown. The user then might get a hint to send the certificate manually to the LDAP.
Hi
I have some questions about the "auto-key-upload: If an LDAP keyserver is configured (in dirmngr), upload a newly created key directly to that server" feature:
- If an LDAP keyserver is configured, will every newly created key be uploaded? Is this upload behavior enabled by default?
- Even with an LDAP keyserver configured, what if we don’t want to upload by default? If we prefer manual approval or want to upload only a specific subkey, how should we handle that?
- What about keys created for testing, temporary use, or personal privacy-sensitive purposes that we don’t want others to discover?
People who use GPG tend to care deeply about privacy and don’t want to upload or expose unnecessary information.
re 1: Only if the option --auto-key-upload is used/configured.
re 2: Do not configure --auto-key-upload but give it on the command line.
re 3: Do not use --auto-key-upload - maybe I should add a --no-auto-key-upload option.
The thing with LDAP servers is that hey are deployed in a controlled environment and not on the public internet. That contracts can be used to punish any abuse. Having an LDAP server on the public internet would bring us back all the problems we have seen with public keyservers: DoS, "faked" keys, and no usable way to delete a key.