I think the option you are looking for is "--homedir" with that option on the command line you can redirect where GnuPG looks for options and keys.

Please try using the current version (3.1.14) and if the problem persists re-open this bug. In this case we will also need a more detailed report.

(Reporter has problems running his own keyserver and accessing it.)

When building from git make sure that you have all tools installed and use
./autogen.sh --force
before running configure. Do not use autoreconf etc.

Hartmut, please read Andre's mail again - we can't do anything about it if Outlook considers an extra delay of 20ms as too slow.

Andre,

thats wrong.
if i disable the Addin, the effect is gone.

Best regards
Hartmut

Von: aheinecke (Andre Heinecke) <noreply@dev.gnupg.org>
Gesendet: Freitag, 11. Dezember 2020 08:35
An: hartmut.jacobi@hotmail.de
Betreff: [Task] [Closed] T5176: Problem with Office 365 GnuPG Outlook addin, Outlook reports not to be primary Mail client

aheinecke closed this task as "Invalid".
aheinecke added a comment.

Hi, you can change the default mail app under systemsettings in windwos 10, this has nothing to do with GpgOL, and the delayed start report, I can't do anything about. Outlook just shows this for any COM Addin to shift the blame, seriously we took 0,02s or 20ms on your system for our initialization. That is reasonably fast.

TASK DETAIL
https://dev.gnupg.org/T5176

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, gnupg, HackyJ, Neurone, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

Hi, you can change the default mail app under systemsettings in windwos 10, this has nothing to do with GpgOL, and the delayed start report, I can't do anything about. Outlook just shows this for any COM Addin to shift the blame, seriously we took 0,02s or 20ms on your system for our initialization. That is reasonably fast.

There's a wildcard CNAME, it's not _really_ configured. It's not a good assumption that a CNAME == configured and it doesn't have a reasonable fallback, IMHO.

If you configure the subdomain in the DNS this will be used. Thus get a cert for it. The old method should not be used and thus if the openpgpkey subdomain exists gpg concludes that the admin is aware of the new scheme.

Hm, I don't want to remove the CNAME just so that GPG WKD would work, is there a way to fix this? Is there a good reason why after "Advanced"/subdomain lookup it doesn't try "direct"?

Oh, it's using the openpgpkey subdomain because of the CNAME but that's not actually being served by the server.

Thank you very much

Select your key in the certificate view, click right, select "Backup Secret keys ...", store to a file. Then copy that file in a secure why (USB stick etc) to the new box, import it there.

I am sorry, but this is not a help desk but a bug tracker. See https://gpg4win.org or https://gnupg.org to find out which community support is available.

Please ask on a mailing list - this is a bug tracker and somehow expects bug descriptions.

This is a support question. Please use one of the public support channels as listed at gnupg.org or ask for a quote at a commercial service (https://gnupg.org/service.html).

Let me comment this

I am sharing completed info, please look into it, at may I know the cause
gpg: enabled debug flags: lookup
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_PROD_2020'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key 88BEBD28 (all)(req_usage=1)
gpg: DBG: checking subkey 022E17B7
gpg: DBG: subkey might be fine
gpg: DBG: using key 022E17B7
gpg: using subkey F423A07D022E17B7 instead of primary key 9D09927E88BEBD28
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_UAT_2019'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: LONG_KID: 'BFFCAF61B48701FD'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key B48701FD (all)(req_usage=0)
gpg: DBG: using key B48701FD
gpg: using pgp trust model
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key B48701FD (all)(req_usage=2)
gpg: DBG: checking subkey 403048E0
gpg: DBG: usage does not match: want=2 have=1
gpg: DBG: no suitable subkeys found - trying primary
gpg: DBG: primary key usage does not match: want=2 have=5
gpg: DBG: no suitable key found - giving up
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_UAT_2019'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: JPMCBANK_GPG_UAT_2019: skipped: Unusable public key
gpg: E:\New\steps.txt: sign+encrypt failed: Unusable public key
gpg: secmem usage: 1376/32768 bytes in 3 blocks

You might want to look at: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

Without more information, we can not act on this.

Please ask on the gnupg-users at gnupg.org mailing list for help. Note that you
do not need to subscribe but just a wait a bit until our moderators will approve
your mail. But anyway here is a quick hint in case you did not already tried:

$ gpg --card-edit
gpg/card> admin
gpg/card> factory-reset