gpg-wks-client is used to send requests to a Web Key
Service provider. This is usuallay done to upload a key into a Web
With the --supported command the caller can test whether a site supports the Web Key Service. The argument is an arbitray address in the to be tested domain. For example firstname.lastname@example.org. The command returns success if the Web Key Service is supported. The operation is silent; to get diagnostic output use the option --verbose.
With the --check command the caller can test whether a key exists for a supplied mail address. The command returns success if a key is available.
The --create command is used to send a request for
publication in the Web Key Directory. The arguments are the
fingerprint of the key and the user id to publish. The output from
the command is a properly formatted mail with all standard headers.
This mail can be fed to
sendmail(8) or any other tool to
actually send that mail. If
sendmail(8) is installed the
option --send can be used to directly send the created
request. If the provider request a ’mailbox-only’ user id and no such
user id is found,
gpg-wks-client will try an additional user
The --receive and --read commands are used to process confirmation mails as send from the service provider. The former expects an encrypted MIME messages, the latter an already decrypted MIME message. The result of these commands are another mail which can be send in the same way as the mail created with --create.
gpg-wks-client is not commonly invoked directly and thus it
is not installed in the bin directory. Here is an example how it can
be invoked manually to check for a Web Key Directory entry for
$(gpgconf --list-dirs libexecdir)/gpg-wks-client --check email@example.com
gpg-wks-client understands these options:
Directly send created mails using the
Requires installation of that command.
Write the created mail to file instead of stdout. Note that the
- for file is the same as writing to stdout.
Write special status strings to the file descriptor n. This program returns only the status messages SUCCESS or FAILURE which are helpful when the caller uses a double fork approach and can’t easily get the return code of the process.
Enable extra informational output.
Disable almost all informational output.
Print version of the program and exit.
Display a brief help page and exit.