There should be a backup file in these cases.

I would suggest to close this as won't fix.

In 2.2 we implemented --import-option show-only which dies the right thing, that is to use the reguarl key-listing code. Backporting this to 1.4 does not make sense - people should move on and use gpg 2.2.

Given that we received no info after nearly two years, shouldn't we simply assume that this bug as been fixed?

This patch was released with 1.4.22

Thanks for testing. Did you try with a powershell?

Tried this on Windows 8.1 (x64) with GnuPG 2.2.1 (libgcrypt 1.8.1) and was not able to reproduce it.

I can replicate this now. Unfortunately without logging enabled.

GnuPG does not mess with suffixes but Kleopatra has some rules of it own which might be common to KDE. I thus flag your report as a feature request.

gpgme shall provide an interface for commonly required tasks but it shall not expose everything from gpg.

This is exactly what I was looking for --> Settings > Configure Kleopatra > Crypto operations > Create signed or encrypted files as text files
Thanks!

I guess it depends on whether you want gpgme to be an interface to OpenPGP certificates more generally (in which case, exposing the primary flag would be useful), or just a gpg frontend (in which case, the current behavior might be ok)

I tried to replicate this but failed. Well, I am on Vista and standard cmd.exe. Can you please try your tests again on a standard cmd.exe shell?

Well we could of course also add code to gpg-agent to verify the card key but the fix I just pushed fixes the problem more easily. If we ever want to implement PASSWD --verify for card keys (which has a couple of side effects) this patch won't be in the way.

Okay, will be fixed in 2.2.2.. I actually found a bug while working on the patch.

@gouttegd provided a patch to implemented that policy. I setup a server server to check this:

gpg -v --fetch-key https://test.gnupg.org/testurl/redirect-to-http.html

Here is a part of the log inline:

I would suggest to close this report even that I have the same problem with the g10 Code cert on Vista - but it used to work when I bought that cert.

It is likely that gpa will be changed to always use the default algorithm. Users who have special requirements will need to use gpg on the command line.

Right, but gpg has a strategy to figure out what it considers the primary (ie. the user id commonly printed). If we would merely convey the primary key flag to gpgme, gpgme or the gpgme calling application still needs to figure out what it considers the primary key - that might be different from what gpg shows.

gnupg 2.1.11 is pretty old and has quite some bugs. Please try at least the Debian version which is 2.1.18 plus a couple of backported fixes. Or yet better, the current stable 2.2.x

Backport to 2.2 done.

Hello Jochen,

There is just another person experiencing the same problem with an Exchange based account on Win10pro x64, Outlook 2016 x86.

I don't have access to this description. I used official, newest releases. I searched for this issue on the web, on the gpg4win page but did not find a solution. Is there any accessible information?

This sound like the issue described in https://wald.intevation.org/forum/message.php?msg_id=5265&group_id=11

In T3457#104401, @werner wrote:

gpg --print-mds  FILES
gpg --print-md ALGO FILES

With that in place, I think there is no need to add them to the PATH.

So far we could recreate the following issues:

DLL hell. There are no command line tools and thus tehre is no need to put them into PATH. Well, except for the shasums - if that is really required, put them into a different directory but that needs to synced with Kleopatras use.

In what kind of problem should we run by adding it to the path?

The gpg4win 3.0 installer does not have the option to install documentation, therefore the docs are missing on purpose. This is done to lower the footprint of the installer, but they are of coursestill available via the homepage.

Fixed in master. Backport to 2.2 pending.

Why should that be useful? It will only run us into lot of problems.

Additional report in https://wald.intevation.org/forum/message.php?msg_id=5308

This comment in the gpg code is relevant for the bug:

/* Verify the passphrase now so that we get a cache item for the
 * primary key passphrase.  The agent also returns a passphrase
 * nonce, which we can use to set the passphrase for the subkey to
 * that of the primary key.  */

Hello.
I am having the same problem with my Yubikey v4.

Potentially useful to know: This is how the import looks like into an empty ~/.gnupg directory:

But there can be several user IDs that are marked primary, right? I know that gpg tries to not let that happen, but there are other OpenPGP toolkits out there, and composite/hybridized keys, etc where this could happen.

This is the updated patch with sm3.c. The others are not touched.

There are more Logfiles:

Then this is a duplicate of T3442 as well! Thank you for you Logfiles and your report!

In T3454#104310, @gniibe wrote:

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

In T3454#104309, @gniibe wrote:

Thank you. The diff doesn't include sm3.c. Could you please update?

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

Thank you. The diff doesn't include sm3.c. Could you please update?

This is the review request link: https://dev.gnupg.org/D449

I have both types of certificates stored in kleopatra; S/MIME from StartCOM and OpenPGP created by Kleopatra.