Sorry for the delay, the passphrase is 512 characters long (now I should change
it after publishing that here ;-)) and just ascii characters.

With GnuPG 1.x, Enigmail takes care of presenting the passphrase dialog.
With GnuPG 2.x GnuPG does it of its own. For that it spawns a small tool
called pinentry which asks for the passphrase. We actually have several
versions of that pinentry. The one you are using is based on Qt (a toolkit) and
has a limit of 256 bytes for the passphrase. The limit may actually be lower if
you are using non-ascii characters, but I can't see how that value is not
sufficient.

How long is your passphrase and does it contain many non-ascii characters (e.g.
Umlauts)?

Hello, Thank you for your reply.

I used the gpg4win-2.2.1.exe binary which I downloaded from gpg4win.org

The popup I mentioned is the screen that asks me for my password when I try to
open an encrypted mail in my mailbox via thunderbird/enigmail. See the
screenshot. In the newer gpg version this popup is replaced by a prompt screen
that says pinentry and will allow only for shorter passwords.

I understand that my password is exceptional long, as I still was (and maybe
still am) a beginner on the encrypted mail part. But backwards compatibility
seems pretty important in the case of encrypted mails and passwords to decrypt them.

What do you mean by "openpgp popup"?

Which installation options did you used whethn installing gpg4win? Depending on
the version you get a different pinentry version - we have a qt based one, a GTK
based base, and a very simple native windows pinentry.

sorry can't delete

Mmmh when I run:

#include <stdio.h>
int _dowildcard = -1;
int main (int argc, char **argv)
{

int i = 0;
for ( i = 0; i< argc; i++) {
    printf("%s\n", argv[i]);
}
return 0;

}

With the command line *.* it just prints "*.*". Linking with CRT_glob.o directly
also leads to the same result.

Hi,
there is apparently a compile option "enable-wildcard" for the mingw-w64 c runtime.

But from:
http://mingw-w64.sourcearchive.com/documentation/0~20100125-3/wildcard_8c-source.html

I take it that you can also enable it in the program by defining int _dowildcard

-1;

I'll test it and let you know if this worked.

For diagnostic reasons: could you try with Kleopatra as well?

Maybe this is relevant:
I only installed gpg, gpgEX and GPA from the GPG4Win package.

Using gpg.exe on the command line works perfect.
I can en- and decrypt files and sign and whatnot.
Only gpgEX is affected.

The crash happen regardless of what I did before. Usually I use Q-Dir as file
browser. When I trigger a gpgex action via context menu in one Q-Dir OR Windows
Explorer the program (the one I used) crashes.

I set GNUPGHOME as a user variable via Windows' Extended System Settings.

I followed Bernhard's suggestion and attached the GpgEX debug log.

Please provide a proper bug report so that we are able to replicate this. For
example, how did you set GNUGHOME, what process have been started before that
etc. A complete run trough on how to exhibit the bug would be a appreciated.

Thanks for asking again, I did not remember that GPGex was missing from the
compendium.

It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html

Actually, I can't.
The link you provided leads to a site with some general infos.
There is another link into the compendium with infos about
some GPG4Win components but not a single word on gpgex.

So HOW do I provide some more diagnostic output?

works with Gpg4win 2.2.0. But there is a failure after decrypting folder with
umlauts: see gpg4win wald issue #6451
(https://wald.intevation.org/tracker/index.php?func=detail&aid=6451&group_id=11&atid=126)

Fixed in d3f20e7. Applied patch to gpg4win as well.

In the backtrace gpa_backtrace2.png you can see that the crash happens:
https://bugzilla.gnome.org/show_bug.cgi?id=696232

If we apply the patch it no longer crashes, but as the error handling in that
patch is just to abort, the text is not copied into the clipboard and we do not
get an error in GPA.

So still some more debugging why invalid utf-8 data is sent from gpa.
As the data worked on comes from GPA and "should" be valid utf-8

Backtrace attached. Sorry that it is an image but windows was blocking me from
copying the gdb output to the clipboard.

Let's assume that the problem was in the glib library and has been fixed in the
meantime. I will soon release a new Gpg4win version with the latest stable glib
version. Feel free to reopen if you still encounter this problem.

Yeah sure, I meant "NOT a problem".

Yes I know what you mean. But without locking you will never be able
to get it right.

As you noted there is actually a problem with Libgcrypt under
Windows. In Libgcrypt we lock the seed file and thus the fatal error
is the right thing to do. But.....

  #ifdef __GCC__
  #warning Check whether we can lock on Windows.
  #endif
  #if LOCK_SEED_FILE

Thus we should implement locking for Windows. The problem here is
that there is no portable advisory locking in Windows. And frankly our
fcntl locking approach does not work on all Unices either and worse it
does not work if the home partition is on certain remote file systems.

The only solution I see is to employ the new dotlock code from GnuPG
here. It is slower than fcntl locking but very portable.

I don't think we will fix this in gpg 1.4.

This is known but a problem from a security POV.

I suppose you mean "NOT a problem"? I think it might be a problem in
opportunistic encryption scenarios if gpg encryption failures caused by
random_seed access conflicts are ignored like failures caused by missing keys.
But usually it's just a nuisance like any other randomly failing program.

The non-locking read is on purpose - if it works: okay. Otherwise we
re-generate a seed file.

I see that the code tries to tolerate access conflicts, but there's still a race
condition if the random_seed file is truncated between fstat() and read(). The
read() error handling is incomplete. Maybe this pseudo-patch explains best what
I mean:

diff -ru gnupg-1.4.12/cipher/random.c gnupg-1.4.12/cipher/random.c

• gnupg-1.4.12/cipher/random.c 2012-01-24 09:45:41.000000000 +0100

+++ gnupg-1.4.12/cipher/random.c 2012-09-18 19:47:54.449578800 +0200
@@ -492,11 +492,17 @@

    do {
	n = read( fd, buffer, POOLSIZE );
    } while( n == -1 && errno == EINTR );

• if( n != POOLSIZE ) {

+ if( n == -1 ) {

	log_fatal(_("can't read `%s': %s\n"), seed_file_name,strerror(errno) );
	close(fd);
	return 0;
    }

+ else if ( n == 0 ) {
+ ... handle like sb.st_size == 0
+ }
+ else if ( n != POOLSIZE ) {
+ ... handle like sb.st_size != POOLSIZ
+ }

     close(fd);

Yes, we could do the file locking

Proper locking would be the ideal solution, but a better read() error handling
would already be sufficient to avoid the sporadic fatal errors on random_seed
accesses.

and iirc, we do this in libgcrypt (GnuPG-2).

I'm just checking this and ... sorry, no. The gpg2.exe from Gpg4win 2.1.0 shows
the very same error:

note: random_seed file is empty
note: random_seed file is empty
Fatal: can't read `C:/Dokumente und
Einstellungen/jechternach/Anwendungsdaten/GnuPG /random_seed': No such file or
directory

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
note: random_seed file is empty

This is known but a problem from a security POV. The seed file is a cache. If
the seed file can't be read a new one is created. Right, there might be a
performance issue but at least on Windows this is not as severe as on certain
Linux systems.

The non-locking read is on purpose - if it works: okay. Otherwise we
re-generate a seed file. Yes, we could do the file locking and iirc, we do this
in libgcrypt (GnuPG-2).

The error on short reads is also on purpose. We want those 600 bytes at once
and nothing else. If another process is writing the seed file we may see the
short reads. But in this case there is no clear answer waht to do - thus we
assume the "no seed file" case.

Libgcrypt does not support 64 bit Windows yet. In particular do not use it even
if it would build and run fine. MSVC is not a supported build platform anyway.

Thanks, Werner, for your reply and your suggestions. I'll have a look at the
GPGME solution.

This is a long standing problem. Usually GPG is used by other utilities and
they exepct utf-8. Thus we would habe to detect the plain use of the console
and then dosomething about it.

No response to my last message. It seems to be an IPC bug and not related to
GPG given that other GUIs don't have these problems.

Fixed in dirmngr and also in GnuPG trunk. Patch for gpg4win created.

ping, it's important for gpg4win.

No info received - assuming everything is fine now.

I have not tried with differnt volumes, but the current gpg4win release works
fine with regards to admin and normal user. Harry, can you please test if this
is still an issue, or if you have moved on from Windows 2000, I will just close
the report.

No time to look into this. Hints on how to fix this are of course welcomes

And why you won't fix it?

[In may previous message I meant "gpg does not _wait_ for the end ..."]

I noticed that the status of this issue was changed to resolved and was
wondering if that meant that it will work in a future version of gnupg or if
it means that nothing will/can be done for the Windows version, i.e. a disk
write will be required each time, and the issue is just closed?

According to the manual and also by a quick look at the code of
g_file_get_contents(), which is called before g_utf8_validate, it should never
return TRUE and store NULL at content. Thus I can't figure the real reason for
this by only looking at the code. Needs more debugging.