I would prefer to store legacy manuals on the web server. That is the easier solution.

@werner, because we have talked about it:

@rupor-github no problem for the delay. Thanks for explaining!

@bernhard Sorry for the delayed answer, was on sabbatical.

Fixed in gpgex 1.0.8

@rupor-github no problem! :)

@bernhard thank you for explaining, did not mean to offend anybody. Before creating win-gpg-agent I tried to read as much as I could on a history and obviously had to study source a bit. Be it as it may - I decided to have separate wrapper, rather then contributing directly to gpg code base. There is noticable number of use cases on Windows which presently not addressed, some I believe are sitting it the queue already.

@rupor-github thanks for your explanations and the contribution to the GnuPG and crypto Free Software code base!

Since Windows user naively could expect multiple methods of accessing certificates from different programs (or sometimes from the same program but different supported environments, like Git4Win and git in WSL) to work together transparently, win-gpg-agent covers translation of one accidentally supported method (32 bit putty shared memory) to multiple unsupported ones (named pipe, cygwin, etc). It also takes care of managing gpg-agent.exe lifetime tying it to user login session for convenience. It uses command line parameters to only to overwrite staff critical to its functionality and does not prevent user from having configuration file(s). Optionally it provides pinentry which is integrated with Windows native Crypto Vault and UX rather than using wonderful QT or GTK. As specified in documentation when developers of gpg and WIndows will get their act together and figure out what they want and how they want it - most of functionality would not be needed. I would like to point out that simply claiming superiority and not supporting cygwin (Git4Win) or working Assuan ssh socket or putty shared memory in 64 bits Windows build does not help with user experience a single bit.

Lots of detailed documentation but frankly, after a brief read I have not yet figured out what it really does. We won't support Cygwin stuff - this is all obsolete and awe also removed starting gpg-agent as a service for good reasons. Instead of starting gpg-agent with lot of command line args it would be better to put this into a per user or system wide config file.

There is a user report that got things to work with https://github.com/rupor-github/win-gpg-agent
on https://wald.intevation.org/forum/forum.php?thread_id=2359&forum_id=21&group_id=11

Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.

Okay.

Alternative patch for Kleopatra:

diff --git a/src/uiserver/uiserver.cpp b/src/uiserver/uiserver.cpp
index d9746f0b..ab4d2ca7 100644
--- a/src/uiserver/uiserver.cpp
+++ b/src/uiserver/uiserver.cpp
@@ -23,6 +23,8 @@
 #include "kleopatra_debug.h"
 #include <KLocalizedString>

Not from understanding. libkleo adds high-level functionality that's useful for KDE applications, but out-of-scope for gpgme and its C++/Qt wrappers gpgme++ and qgpgme. I would use GpgME::dirInfo() directly in Kleopatra. It would make sense to add an overload of GpgME::dirInfo() that takes an enum, so that one does not have to use the low-level string names in Kleopatra. The downside is that a string-based interface can be extended easily. OTOH, deprecating values of a string-based interface is hard and after removing it the compiler won't complain.

We want to deprecate the whole UI-Server thing and thus I considered it better to provide the generic socket dir instead of adding support in libkleo for the uiserver socket. For the time being, doing this in Kleopatra sounds better to me. From my understanding. libkleo shall be an interface to gpgme++, right?

gpgme_get_dirinfo does already have support for "uiserver-socket" since about 7 years. I don't think a separate "socketdir" which requires a brand new gpgme makes much sense.

For Kleopatra this patch

It will be useful to have support in libkleo:

Tried and no change -- cmd window still flashes away.

Remember to always pass --batch for unattended operations.

Thanks to jaclaz@msfn.org, the workaround is to use pipe operation like:
pause|"C:\Program Files\GnuPG\bin\gpg.exe" --verify "%1"
He also confirmed that gpg.exe does interrupt batch processing, regardless what command is followed.
And I have tested in Windows 7, batch processing is not interrupted. Since this bug is WindowsXp specific, "won't fix" should be more proper.

Sorry, GnuPG proper has no context menu or any graphic user interface. You need to install Gpg4win for this. Regarding use of gpg by other programs: There has been no change - other programs need to use the status-fd/command-fd interface and that has always been defined as UTF-8 and not as any native codepage. Please ask the makers of The Bat what is going wrong there.

Just for the record, Kleopatra and Gpg4win work totally fine for me on Windows-11 preview.

It is quite likeley that things don't work on a non-released Windows version. We have not tested with the released version but some of us already tried Windows-11 and the gog4win development versions do work. Please wait for the next Gpg4win version or an update of the Windows-11 preview.

So it is related to code page. Screenshots may be more informative:

Frankly, I don fully understand your report. Can you please clarify?
Note that with 2.2.8 we introduced full Unicode support on the command line. If you see scrambled output you may want to "chcp 65001" to get the output correctly rendered.

I have done tests with 2.2 and no problems showed up.

Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!

I just had the same issue as hurui200320. My user name contains a "ç" and Kleopatra did not start. The Windows event logger reported a crash in libstdc++-6.dll. This was with gpg4win-3.1.16. Installing gnupg 2.3.1 did not change anything.

It is a matter of the used font. 2.2.29 will fix this problem.

Same error message in Windows 8.1 x64 with the commands:
gpg --local-user 0x12345678 --sign-key 0xABCDEF12 or: gpg --default-key 0x12345678 --sign-key 0xABCDEF12.

I did some test on Windows 10 using gnupg 2.2 with this patch and things work.

For testing ion Windows 10 you need to switch to "Legacy Console" and reboot.

I think that a patch like following is needed:

diff --git a/common/ttyio.c b/common/ttyio.c
index c385700de..55468bdf0 100644
--- a/common/ttyio.c
+++ b/common/ttyio.c
@@ -236,7 +236,21 @@ w32_write_console (const char *string)
   n = wcslen (wstring);

When console font is not a Unicode font, it seems that the WriteConsoleW function may return ERROR_GEN_FAILURE.

Hello Mr. Koch,

Please run

Hello Mr. Koch,

Are you using Powershell or another non-standard shell? Which windows version are you using? Do you use default-key in gpg.conf? Do you have a smartcard inserted?

With sqlite3 using -static-libgcc, I confirmed that GnuPG and its friends are built well with newer mingw on bullseye. And I lightly tested GnuPG on Windows.

Ah, I realized that the build for sqlite3 in Speedo has a patch using -static-libgcc.

We use libgcc_s_sjlj-1.dll only for for gpg4win's C++ code which is gpgme's c++ binding and the Qt stuff.

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.

(I disabled the account of this boor)

I don't think that it is --pcsc-shared related; Andre reported that he noticed such a behaviour before we introduced this.

I wonder if PCSC_SHARE_SHARED is related or not.

Given that we don't yet support TPM for Windows you should go ahead and apply this patch. tpm should also be removed from the list of components.

gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.

yep, Should be fixed in libgpg-error/src/w32-gettext.c unless we want a way to retrieve the meat data. We can also and faster fix this in gnupg proper.

Example from gpg.c:

ARGPARSE_s_n (oQuiet,	  "quiet",   N_("be somewhat more quiet")),
[...]
ARGPARSE_s_n (oNoGreeting, "no-greeting", "@"),

The quiet option has a human readable description, but the no-greeting option does not have one. Consequently, gpgconf --list-options gpg gives the following result:

[...]
quiet:0:0:be somewhat more quiet:0:0::::
no-greeting:0:3::0:0::::1
[...]

For comparison, on an English Linux system the options also look wrong, i.e. all options that are problematic in the German translation are "raw" option names enclosed in double quotes. It seems that the untranslated description of the options is already missing.

Btw this only occurs for some options:

That it. Things works nicely for me. Won't be backported to 2.2 because this introduces minor changes in the behaviour.

Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

Reopening this as I have seen such hangs multiple times during testing. When importing multiple keys with Kleopatra at once this can be reproduced sometimes.

Thanks for your answers. If you see another problem with kleopatra, please test the latest Kleopatra version which we will release the next days.

1. I created another handful of key pairs and tested around. However, I could not recreate the problem now. I can store the secret key in Kleopatra, but the file differs from the backup key. It seems to be a stub indeed. And even if I want to perform an operation directly in Kleopatra, the smartcard is requested.

Why do you think you can still export more than a stub key?

The listing shows that the private keys are stored on a card ("sec>", "ssb>"). Why do you think you can still export more than a stub key? If I export a test key (just the primary key in this case) and run "gpg --show-keys" on the exported file I get the expected "sec>" marker. Looking with --list-packets at it we get:

The exact commands given and the output. Adding -v is always helpful.

Hi, I'm the user that reported this bug.

On Thu, 7 Jan 2021 09:56, bernhard (Bernhard Reiter) said:

The user reported to

Please describe exactly what you did so that we can replicate this.

I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.