Can you help me please to understand why you think that this is a regular use case?

Fairly typical situation: user needs to encrypt binary and text regularly

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

@aheinecke , Would you consider re-opening this ticket?

I'm going to push this change to master.

Wow, thanks for the quick response! I've applied your patch to the Ubuntu package (2.2.4-1ubuntu1.2), and gpg --card-status now works fine:

I'm not really sure if "No Key" is a better string for "Ignore Recipient". But most other things are either unclear (ignore recipient) or can be misunderstood like (Do not encrypt to this recipient) as this could also mean that the recipient gets an unencrypted mail.

It now looks like this:

@dkg This patch ( rP0e2e53) might also be something for debian as it can cause crashes depending on the qt theme, which is not under our control.

Thanks!

I can confirm that the patch from the referenced commit fixes the issue. Thanks for the quick action!

@aheinecke

Due to socket forwarding we can have different versions of gpg-agent and gpg / gpgsm because they are on different machines and afaik we try to support it.

In rGfdd1567743cc1d526f92e63162d899a24c42cdf4#61654, @gniibe wrote:

As far as I know, usually, gpg/gpgsm can assume same version of gpg-agent.

fwiw, if the old gcrypt actually returned a radically different API, it should have a larger SONAME across that change, and NEED_LIBGCRYPT_VERSION should reflect a source version that forces it past that SONAME. I don't know what version of libgcrypt behaved differently -- is there a reference for that?

I don't think there's a problem to have a long explanatory message in the main repository, as i think it makes it easier to understand, and space is not an issue.

thanks for the report. I've commited a different fix 0e2e53c8987d6f236aaef515eb005e8e86397fbc which also should solve the problem.

Adding the patch here.

I was afraid that there are wrong usage where HANDLE is passed where int for fd is expected (or opposite).
But it seems, there are only usage where it should be gnupg_fd_t ideally but using int.

I'd like to push your change to master, if possible with exact check.
Do you intend to put your comment to the master repo? Or, it's for discussion?
It's OK for your topic branch, but, I feel that it would be too long to be included to master repo.

I'm confusing if following API should use gnupg_fd_t or not:

• iobuf_fdopen, iobuf_fdopen_nc
  • Perhaps, these are using int for fd, like es_fdopen
• set_attrib_fd ?
• read_passphrase_from_fd ?
• set_status_fd ?
• is_secured_file ?

As far as I know, usually, gpg/gpgsm can assume same version of gpg-agent.

I pushed a fix to master: rG858dc9564326: scd: Fix bBWI value.

Except w32_system function, it's done.

APIs which need revise (where we use pid_t):

API which uses int for fd:
GnuPG common:

• gnupg_create_pipe, gnupg_create_outbound_pipe, gnupg_create_inbound_pipe
• gnupg_spawn_process_fd

gpgrt:

• gpgrt_make_pipe (not yet exposed to public API)
• gpgrt_spawn_process_fd (not yet exposed to public API)

HANDLE type casting to long is wrong (it results masking the value to 32-bit, which is not needed).
I fixed:

• rGa64411c607d5: common,w32: Fix cast from gnupg_fd_t to call _open_osfhandle.
• rE655ed9d83889: w32: Fix HANDLE to internal fd conversion.
• rEf93a0358dc82: w32: Fix cast to internal fd.

I've just broken out my changes into two commits, one that makes gpg and gpgsm more robust. That should be applicable without any risk.

I see your point (I am also the one who implements reader/token). That's reasonable argument.

Thanks for your report, with helpful log.

thanks for the report and trying to help with Gpg4win. The underlying problem is that our backend (GnuPG) does not provide proper error handling when changing the expiry date. We already had an issue for that so I've merged this task with T4395.

I've just posted rGb84feb0c82eb to the dkg-fix-T4652 branch, which solves the failure problems by making agent_pkdecrypt and gpgsm_agent_pkdecrypt more robust.

fwiw, this patch appears to cause gpgsm to fail its test suite:

I've just pushed rG1ae16838660a to the dkg-fix-T4652 branch (i just adjusted it the commit message to include the GnuPG-bug-id)

I installed microsoft office 2016 on a brand new laptop and got the same problem described in the post listed above.
My solution was to uninstall the pre-configured app : "Microsoft Office Desktop Apps" and voila!!

Thanks aheinecke and dkg.
I havent been able to replicate the fault using the command line (using the exact same command and options that our program is calling)
however our R&D dept have,
The next time it fails and we can replicate it we will try the --homedir fix and see if thats it.
Its the same user in the program and command prompt so we dont think its a certificate issue.

when you double click a key and then click "Export" you get a copy & paste version of the key.

Thanks for the report. It is always good to have such issues documented.

This pretty much matches my test setup. As the crash is in GPGME it is out of Kleopatra's hand. So I'll try to write a test that repeats such a signing for lots of times. I think this is probably some random race condition.

I think that even if the reason is corrupted keys it would be good to handle this better, either in Kleopatra or in GnuPG. e.g. Kleopatra could detect if a keylisting takes too long and offer to do some cleanup programatically.

I don't think I can reproduce it, at least it didn't happen anymore after restarting and continuing the imports. AFAIR it happened after importing the "Master Key", during trying to import the "Release Key" from https://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html
Ah and maybe one more hint: I have several keypairs, so the dialog for choosing the keypair to be used appears in the next step.

I'm also not sure how to classify this issue. I'm giving it low priority for now as we do not have the info to determine if this is a program error.

I think we had that issue in the past and solved it. It probably broke again. There is an external library we use for this dialog and that might have regressed in the latest update.

Mmh, the error log only tells me that it crashed in our GPGME library. So it is a bug in our software.

Hi Florian,

This report doesn't contain enough information to be able to tell you why the command is failing within your program, but not failing outside of it.

Thanks for clarification.
However, CCID_CMD_TIMEOUT should be then based on BWT value reported by the card/reader, as bulk_in() function will still timeout if BWT is longer than 5 seconds.

Thanks for pointing me in the right direction. I was confused by the hard-coded timeout value and got it all wrong.