Setting up wks/ error parsing submission email
wk at gnupg.org
Sun Dec 23 11:59:21 CET 2018
On Fri, 21 Dec 2018 15:18, fsantiago at deviltracks.net said:
> webkey at mail:/var/vmail/procmail$ /usr/lib/gnupg/gpg-wks-client
> --verbose --debug crypto --receive --send < sample2.txt
> gpg-wks-client: gpg: Good signature from
> "key-submission at deviltracks.net" [unknown]
The signature from the server. The server signs the confirmation
request to allow the client to detect malicious requests before annoying
the user with a request to decrypt the challenge. All good here.
> gpg-wks-client: DBG: gpg status: ENC_TO FAD6496868B818DD 1 0
> gpg-wks-client: gpg: encrypted with RSA key, ID FAD6496868B818DD
The encrypted challenge. The client must be able to decrypt this to
confirm the publication requests he sent.
> gpg-wks-client: DBG: gpg status: NO_SECKEY FAD6496868B818DD
But for whatever reason the client does now own that private key.
> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
Sure that this is the same gpg version you used to create the challenge?
> that key id mentioned as missing, "FAD6496868B818DD", is that of my
> test123 address from my client testbed. i would have assumed it would
> be encrypted to the key-submission address' key. am i wrong? is it so
No. You encrypt your publication request to the submission address
key. This is not required for the protocol but we want to encrypt as much
traffic as possible.
The server then encrypts to the key you want to have published.
> that i could also read the message in my sent folder so it's encrypted
> to both of us? i'm just thinking aloud. let me know what you
The server does not need to decrypt its own challenge again.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 227 bytes
Desc: not available
More information about the Gnupg-devel