Please update the documentation for the function in that case.

Please see my explanation on gnupg-devel about why the trailing NUL is a source of pain and difficulty for would-be adopters.

Lacking another category for such things, I dropped the priority.

Well, gpa needs to use gpgme's interface for receiving and sending keys. The use of the helper programs an old hack.

Right, master will be 2.3.

Actually all this code shall be replaced by new code from gpgrt. Most likely using estream_t for all of them.

No, it was not in mind. I introduced this only for backward compatibility. It will be extended iff we have a need for it.

Appending a nul byte is fail-safe programming and helps in debugging. It is on purpose and shall not be removed.

Actually my not-written-down plan is to use a Windows like style for tracking a process. This will also resolve the pid rollover problem. It shall all go into gpgrt of course.

My understanding is: it was introduced by rG370f841a0135: Enhanced last patch. in 2009 to give information to client (for a specific command at that time), possibly in a hope that server side would support the feature for all commands (and client could benefits).

I think the problem is the following:

False alarm. Turns out pinentry-gtk-2.exe is also not working all the time.

@bb - I've tried this, this doesn't appear to work. It looks like the Gtk2 pinentry doesn't grab focus when doing authentication, either. Interestingly enough, it also doesn't show in the taskbar.

Note:
I added:

pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-gtk-2.exe"

as a workaround to my gpg-agent.conf. This pinentry is able to grab the focus.

The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.

Does anyone has an update on this issue?

I've just uploaded pinentry 1.1.0-3 to debian unstable with this fix in it.

@aheinecke thanks for the heads-up. i'll pull this in.

Thanks. So, this is a positive report for 8E60:34C2. I'm going to add this VID:PID to support pinpad input by the internal CCID driver.

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.

we won't backport it to 2.2

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.