Applied to master.

I created a branch https://dev.gnupg.org/source/gnupg/history/gniibe%252Ft8048 and pushed all changes (including keyboxd-patch-2026-04-23).

As I'd like to have it in vsd34, I'll set that tag (and of course gpd5x, too)

Enhance keyboxd to have new command for what keybox_set_flags does.

FWIW: There is actually a problem in the reference code: Having a
fixed size buffer inside a function and allowing the caller to provide
content at arbitrary length is bad coding style because the caller
needs to know internals of the called function (in a different source
file).

This is the original bug report to security at gnupg dated 2026-04-07:

In T8215#217199, @uwi wrote:

Anyway after reboot I could complete the update. The only think I had noticed was that Kleopatra's hair is blue now (it had been red in the past) ;-)

In T8215#216993, @ikloecker wrote:

By the way, your screenshot shows the wrong folder. That's why you didn't see the file that the error message mentions.

Here is the change:

diff --git a/configure.ac b/configure.ac
index 30be86b5..ac2696e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3073,7 +3073,8 @@ AC_CHECK_FUNCS(strtoul memmove stricmp atexit raise)
 AC_CHECK_FUNCS(strerror rand mmap getpagesize sysconf waitpid wait4)
 AC_CHECK_FUNCS(gettimeofday getrusage gethrtime clock_gettime syslog)
 AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile getauxval elf_aux_info)
-AC_CHECK_FUNCS(explicit_bzero explicit_memset getentropy sysctlbyname)
+AC_CHECK_FUNCS(memset_explicit explicit_bzero explicit_memset)
+AC_CHECK_FUNCS(getentropy sysctlbyname)

Reporter has tested 2.5 - the code in 2.2 is identical; no need for separate testing

I reworked the reading using our dedicated line reading functions which is used at other places. Extra benefit is that the code now also prints a status line ERROR which gives information on the first faulty line. Thus gpg-connect-agent listtrusted /bye can be sued to quickly check for errors without configuring a log file.

Looks good to me on vsd-3.3.7-beta90.9 @ win10:

Looks good to me on vsd-3.3.7-beta90.9 @ win10.

It is also shown in gpd-5.0.2:

I found the description in ARM Architecture Reference Manual:
https://developer.arm.com/documentation/ddi0487/mb/-Part-D-The-AArch64-System-Level-Architecture/-Chapter-D11-The-Guarded-Control-Stack/-D11-1-Introduction/-D11-1-3-Overview?lang=en

By the way, your screenshot shows the wrong folder. That's why you didn't see the file that the error message mentions.

Note that the error message may occur a last time when 5.0.2 (or earlier) is updated to a newer version because the uninstaller of 5.0.2 cannot be fixed retroactively.

gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7

1.8.13 (T8224) and 1.12.2 (T8114) are released

Seems I forgot to note that icon removal works when resetting to defaults. And the VSD related Categories are no longer shown in Gpg4win. Tested now with Gpg4win 5.0.2, but I believe it was already ok in 5.0.0.

Windows 10 since some build number also has real Local Sockets which avoids the trouble with Windows ACLs.

There is no handling for installing a currently in use libwinpthread-1.dll and a few others. That will require a reboot anyway and thus it is only done for the more common cases like gpgol and gpgex. Workaround is to reboot and try again.

PIPE_REJECT_REMOTE_CLIENTS is from windows vista and onwards. I guess that's good enough for us.

This seems to be a newer flag, although not stated in the docs.. Hart does not mention this in Windows Systems Programming either. I recall that I did extensive tests with Named Pipes and Mailslots to find a way to restrict access to local processes only. Sure you can use capabilities to restrict access but that is a pretty complex beast and easy to get wrong. It did not worked back then when I tested this with NT 3.5 or so. Thus our solution was to to use TCP where you can easily specifcy the listening port.

Citing the API documentation of CreateNamedPipe (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea):

One of the following remote-client modes can be specified. Different instances of the same pipe can specify different remote-client modes.

PIPE_REJECT_REMOTE_CLIENTS Connections from remote clients are automatically rejected.
0x00000008

This happens occasionally and is not related to upgrading from 5.0.1 to 5.0.2. It can happen when installing any 5.0.x version (including the betas) over an installed 5.0.x.

With -C <DIRNAME> option, where <DIRNAME> is not exist is OK.

I would like to see a description on how Kdsingleapplication handles the Windows Named Pipes. In particular how does it ensure that there is no way to remotely connect to the named pipe. AFAICR, there is no way in Windows to do that.

The minimum fix avoids changes needed, thus, a bit confusing as a whole.
Here are better changes:

Here is the fix:

I do think that switching from our own copied-around-code to a wider shared component for single-application setups does make very much sense rather than try to battle-harden our own code against scenarios of various likeliness.

I would suggest to move the is_elevated check before checking for running instances and then always terminate the process. For those footgunners we can add a Registry key AllowRunningAsAdmin=footgun as HKCU which prints it only as a warning.

See also T5248

I think we have a regression with this change. This is the old behaviour (gnupg 2.2 in this case, though)

Minimum fix is:

Well, I don't think we'll add platform-specific X11 code to pinentry-qt just to check for an invalid DISPLAY. We are using Qt so that we don't have to deal with platform-specific stuff. I have no intention to look into this and, given Wayland, investing any more time in X11 feels wasted. We might accept a patch that can be used by all GUI pinentries to check for a usable DISPLAY.

"ikloecker (Ingo Klöcker)" wrote:

ikloecker added a comment.

How is "invalid DISPLAY" defined? `DISPLAY=invalid`? Anything that's not `DISPLAY=:<some number>`? Why do screen and tmux have to use an extra-wurst?

[...]

For my own understanding I repeat your explanation with some changes
for clarity:

@werner I can confirm that we've tested the patch and it seems to fix the issue in our setup.

The attack works like this: An unprivileged user starts an application which creates a window like the one Kleopatra looks for. Then the normal user (or an admin) starts Kleopatra. Kleopatra finds the existing window (it looks for any window with the right name) and grants the unprivileged process full access to the Kleopatra process. Now the unprivileged process can do anything the Kleopatra process can do.

This is not a security bug. Consider: The user starts kleopatra as administrator (via runas or an administrator terminal) and then starts a second kleopatra to have a "privilege escalation" - So what is the point - if you can do runas you already have all the privileges you could get with this privilege escalation.

GpgOL/Web is likely also affected.

Applied to master to be release with 2.5.19.

Apparently, DISPLAY is hostname:displaynumber.screennumber where hostname and .screennumber are optional and where hostname is a hostname or maybe host/unix. Does hostname include IPv6 address literals? Anyway, I guess the only sensible heuristic is to consider any DISPLAY value that contains : as valid.

How is "invalid DISPLAY" defined? DISPLAY=invalid? Anything that's not DISPLAY=:<some number>? Why do screen and tmux have to use an extra-wurst?