Here is my attempt:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Fri, Sep 27
It is reproducible bug even with master branch.
Thu, Sep 26
I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.
Wed, Sep 25
Fixed in pinentry 1.3, when using GnuPG 2.4 or later.
Tue, Sep 24
Fixed in libassuan 3.0.0.
Done in GnuPG 2.5.0.
Fri, Sep 20
The change of spawn functions (basically, it was factored out to libgpg-error) results more possibilities to have blocked scdaemon, since the implementation in libgpg-error introduced context switch points when it spawns a child process.
Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.
Thu, Sep 19
Do you have scd-event script in your GNUPGHOME?
I applied rGb804378f183f: kbx: Fix a race condition on DATABASE_HD. in master. Let us see how behavior changes.
I found one problem. This problem may result lock-up on Windows, I suppose.
I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Wed, Sep 18
For POSIX, I found an issue of T7151.
If you are using multiple clients which invoke SCD DEVINFO --watch, the problem should be fixed.
If it's not the case, let us locate a bug (or two).
I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).
Tue, Sep 17
Fixed GnuPG 2.4 in: rG730593affa91: common:w32: Don't expose unused functions.
For now, I'm using this to avoid failure of make check (invoking gpg-agent by gpg-connect-agent).
diff --git a/common/stringhelp.c b/common/stringhelp.c index 9a2265258..6596c65cd 100644 --- a/common/stringhelp.c +++ b/common/stringhelp.c @@ -70,6 +70,22 @@ change_slashes (char *name) { #ifdef HAVE_DOSISH_SYSTEM char *p; + /* 0: don't know yet, 1: it's under wine, -1: no */ + static int semihosted_by_wine; + + /* Under wine, no change. */ + if (!semihosted_by_wine) + { + HMODULE hntdll = GetModuleHandle ("ntdll.dll"); + if (hntdll + && GetProcAddress (hntdll, "wine_get_version")) + semihosted_by_wine = 1; + else + semihosted_by_wine = -1; + } + + if (semihosted_by_wine > 0) + return name;
libgpg-error fix is done in: rEc2a713fe11e3: w32:spawn: Remove unused function get_max_fds.
Mon, Sep 16
Fri, Sep 13
Thu, Sep 12
Wed, Sep 11
Mon, Sep 9
Since CreateProcessW allows two ways for lpEnvironment (one is ANSI environment block, another is Unicode environment block), if we want to support these two ways for users' of gpgrt spawn API, we would offer either:
I'm talking about CreateProcessW and how a user of gpgrt spawn API can specify lpEnvironment (when needed).
Thank you. Applied.
Thank you for the bug report and your patch.
Please note that gpgrt_spawn_actions_set_envvars is W32 specific API in libgpg-error. Currently, the behavior with ASCII string is defined.
The patch is an answer in future if we want to extend the semantics supporting UTF-8.
Fri, Sep 6
Here is my attempt:
Thu, Sep 5
Use of execve is better (avoiding use of environ).
Wed, Sep 4
I re-consider. Adding arguments to existing gcry_kem_keypair is not good since it introduces API break.
Instead, I add gcry_kem_genkey with additional arguments (which can be used for deterministic key generation).