Currently the first call to QGpgMENewCryptoConfig::reloadConfiguration happens in the GpgSM self test. Funnily enough the selftest for gpg just returns true when the empty constructors of the cryptoconfig are called. The first component load is GpgSM.

Hello ...

It is not really helpful if you publish that fact anyway on a public tracker.

We sometimes grant our customers the privilege of receiving updates a few days earlier than the community. It is not really helpful if you publish that fact anyway on a public tracker. BTW, there is no community version gpg4win 3.1.26.

If you enter a wrong password in a window, the error message will only be given after you have answered all requests for the transport passwords.

No. We now ignore expired key with --mirror, --create, and --install-key.

Another idea would be a gpgconf daemon that answers all queries from its in-memory cache. Obviously, this wouldn't help with the very first start unless the daemon is started automatically on login which should probably be default behavior at least on Windows anyway. OTOH, gpgme does already cache the config so this would only have an effect when starting Kleopatra.

Actually we should switch from putenv to SetEnvironmentVariable et al. because that avoids problems wit different Windows libc versions, for example in DLLs.

Fixed in rG8e8971403f75: w32: Fix gnupg_unsetenv..

Done (STABLE-BRANCH-2-2.40 for now)

Yes, I'll do that. Thanks for the reminder.

Any comments on applying these to gnupg-2.2?

On Windows, closing/inheriting handles is different to POSIX.
https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873
https://devblogs.microsoft.com/oldnewthing/20130426-00/?p=4543
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-deleteprocthreadattributelist

We should consider to break the Assuan API maybe we can do that without too many problems for the current use cases.

I'm going to use gnupg_process_* prefix for the functions.

Last two points are for future changes of assuan internal; For the case of controlling fds in detail, it is possible to use spawn callback controlling fds by the routine and let no-touching (inherit) by the spawn function.

I don't understand the last two points: This is only about the three standard descriptors but how shall we supply more descriptors? At least in GPGME we definitely need more.

Evaluating again, I'd like to change spawn functions like this one in libgpg-error:

You need to handle them in a correct way. Just checking with gpg is
not enough because you don't know what has been signed. You need to
look at the signed data which gpg gives you by using the --output
option. And there you see only the signed data and not the extra
"aaa" you added after having signed the plaintext. It is not
different from adding stuff before the -----BEGIN PGP SIGNED ... line.

In T6272#165067, @werner wrote:

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Examining again, I realized that the current spawn API (not published yet, only available in libgpg-error master) is not that useful in general (or difficult to use), while it works somehow.

Here is the change of GnuPG to use new spawn functions from libgpg-error:

For the spawn_cb, I reconsider. Having three calls complicates use, and it is actually not needed. In the case of pthread_atfork, it is needed, because fork may be used deeply in some functions. In our use cases of spawn function, prepare part of the callback can be called before calling spawn, and parent part of the callback can be called after calling spawn.

I decide use of pid_t, as there are different semantics between POSIX and Windows, *and* there is a problem of MinGW-w64. I introduce gpgrt_process_t, instead.

Another thing when we define a type which represents process.
For pid_t, MinGW-w64 has a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1397787 (or https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1456671365-21759-1-git-send-email-sw%40weilnetz.de/).
(1) GetCurrentProcessId always returns 32-bit (DWORD), so, it can be represented in 32-bit (although DWORD is unsigned).
(2) POSIX requires pid_t should be signed integer https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
(3) Original MinGW defines pid_t as int (in include/sys/type.h by _pid_t). (checked in mingwrt-5.4.2)

We won't do that. FWIW: We started to work on a 64 bit WIndows version of GnuPG.

You are using a somewhat special setup and not what has been tested with gpg (i.e. putty). In particular Cygwin based tools do not interoperate well with non-Cygwin tools.

Is this still an issue or is the new gpgconf -X feature sufficient to detect this case?

An outer signature or even a new packet to sign the list of encrypted session keys might also be an option which does not disturb older implementations.

Would running the different --list-options in parallel make sense? Or would the block each other?

@werner - having another argument might be useful. Indeed, pthread_atfork has three callback functions as its arguments (prepare, parent, and child).

I general I agree.

To have clear semantics, I propose a change to gpgrt_spawn_process_fd (calling SPAWN_CB, instead of AFTER_FORK_CB, and give it return value), and exporting gpgrt_close_all_fds to users.

By the commit rE43c1e85fe29a: spawn: Expose spawn functions., spawn functions are exposed now. The API is compatible to the one of internal functions in GnuPG master (2.3).
Semantics is not well-defined portably for:

• gpgrt_spawn_process: EXCEPT only makes sense in POSIX. User could expect that the API does closing all fds except fds specified by EXCEPT in POSIX.
• gpgrt_spawn_process_fd: AFTER_FORK_CB only makes sense in POSIX. User could specify the callback so that it can control sigmask, envvar, open/close/dup-ing file descriptors, making sure releasing some resources beforehand, etc.

In order to remove the SHA-1 algorithm in Arch Linux package keyring, I need to resign one of my sub keys but the backsig (0x19) remain in SHA-1 as reported here.
I didn't find any solution with gnupg to update it since this bug report was opened in 2020. Do you plan to address this in a near future?

I see. I understand the use cases for POSIX to keep some file descriptors.

without this list we don't have an option to keep file descriptors open; its not just stderr but for example log files and descriptors which pare passed by other meands than libassuan functions.

• assuan_pipe_connect and internal _assuan_spawn

Applied also in 2.2 branch.

This also affects 2.2.40. Will the fix be backported there? Thanks.

Thank you, confirmed. Pushing the fix.

This is a debug option; I see no use case for this.

Add --expert and use a decent version of GnuPG. 2.2 is our long term support branch and is not the current stable production version (which is 2.3.7)

Perhaps --full-generate-key should provide more algorithm choices, then, e.g. ed25519?

Sorry, this as been discussed ad nausea. We try our best to help people not to use useless and harmful (e.g. performance of the WoT) algorithm choices.

Yes I do understand Windows XP is not supported. Just in case it is a minor problem that is easy to fix and will not cost you much effort. I'd like to add more information: I do not change
%LOCALAPPDATA%. There is no such environment variable. A similar environment variable is:
APPDATA=C:\Documents and Settings\myname\Application Data
I do set GNUPGHOME=E:\key, which I think should be allowed because I do not want my personal info be stored in system drive.

We should close this. The recent fix in 2.2 and the forthcoming 2.3 does everything we want. In the meantiime or if further problems turn up, --ignore-cert is a good workaround.

This is a support question and not a bug. You should ask such questions on the channels for Gpg4win, which does the Community support for GnuPG on Windows: https://www.gpg4win.org/community.html

No, it does not matter.

E:\key>gpgconf --list-dirs
sysconfdir:C%3a\Documents and Settings\All Users\Application Data\GNU\etc\gnupg
bindir:C%3a\Program Files\gnupg\bin
libexecdir:C%3a\Program Files\gnupg\bin
libdir:C%3a\Program Files\gnupg\lib\gnupg
datadir:C%3a\Program Files\gnupg\share\gnupg
localedir:C%3a\Program Files\gnupg\share\locale
socketdir:E%3a\key
dirmngr-socket:E%3a\key\S.dirmngr
agent-ssh-socket:E%3a\key\S.gpg-agent.ssh
agent-extra-socket:E%3a\key\S.gpg-agent.extra
agent-browser-socket:E%3a\key\S.gpg-agent.browser
agent-socket:E%3a\key\S.gpg-agent
homedir:E%3a\key

The "sysconfdir" "C:\Documents and Settings\All Users\Application Data\GNU" does not exist actually. Does it matter?

I just fixed a bug related to the DP. That might be related. See rG0c8299e2b56ef2e1

That particular bug seems to have been solved a long time ago. I stumbled upon up while fixing a DP bug today.

To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.