I've opened T1775 and only afterwards noticed that this issue did aleardy
exist ;-)

So here is my mesage from T1775 which further qualifies this issue:

This bug was reported by fersingb on IRC, I could reproduce it.

If you have a public keyring in the .kbx format exporting a key with the full
keyid produces an endless output stream.

To reproduce it I can import any key into a newly created gnupg homedir.
When exporting this again using the fingerprint as identifier the bug is triggered.

My usual gnupghome was automatically migrated still has a pubring.gpg and works.

Setup:
FAKEHOME=$(mktemp -d)
gpg2 --armor --export CA308D95A6332F7056B4DFD194F78CF1265059CD | gpg2 --homedir
$FAKEHOME --import

Triggering the bug:

gpg2 --homedir $FAKEHOME --armor --export CA308D95A6332F7056B4DFD194F78CF1265059CD

The short fingerprint works:

gpg2 --homedir $FAKEHOME --armor --export 265059CD

My current version is yesterdays master (2.1.1-beta45) but the original reporter
used gnupg-2.1.0.

Ah damn,..
Duplicate of
T1774

sorry.

Duplicate of T1774

The problem was with that specific keyserver. If I use another keyserver it
works. The keyserver was the first one returned to me by using the
keys.gnupg.net pool and as gpg 1 works with it.

I've debugged the issue.

The test case is now reduced to:
gpg2 --keyserver hkp://127.0.0.1 --search foobar

Dirmngr logs:

2014-11-26 20:35:55 dirmngr[5892.1] getnameinfo returned for '127.0.0.1':
'localhost'
2014-11-26 20:35:55 dirmngr[5892.1] can't connect to '127.0.0.1': Success
2014-11-26 20:35:55 dirmngr[5892.1] error connecting to
'http://127.0.0.1:11371': System error w/o errno
2014-11-26 20:35:55 dirmngr[5892.1] command 'KS_SEARCH' failed: System error w/o
errno

In my case this is because common/http.c (connect_server) ~ line 2200

  ai->ai_family == AF_INET && (flags & HTTP_FLAG_IGNORE_IPv4)

Returns true for 127.0.0.1 (same for 75.75.183.132 which also explains why it
works with gnupg) the address is skipped but it is the only one -> loop finishes
with no errno set.

It is set in dirmngr/ks-engine-hkp.c which looks to me like: "If it is not
indicated that a host either uses IPv4 nor IPv6 ignore it." Which i find kind of
harsh. At least a debug output like:

      if (!hi->v4 && !hi->v6)
        log_debug("Ignoring host\n");

Should be added there and of course connect_server should return an appropiate
error in case it never actually tried to connect to a server.

While debugging this I think I found another issue. You are using errno after
my_connect calls. If this expands to npth_connect the actual calls are

enter_npth()
sem_post() modifies errno
connect() modifies errno
leave_npth()
sem_wait() //modifies errno

Afaik enter / leave in npth should save errno. I could not confirm that this is
really an issue with a test but I think it is.

To little information.

• Can you please describe what you were doing when the crash occured.
• Could you enable the debug mode (described in the compendium) and add the

created log.

• Are you using an Exchange server together with outlook?

This was fixed in gpg4win 2.2.2

Yep, I'm using Kleo/Kmail now with 2.1 and I don't see any issues.

I've closed your Bug against kleopatra accordingly.

I also don't think that there will be much "Does not work at all" issues but
rather "There is no gui for this or that configuration option / no gui for ECC
Key creation" etc. So this is not really a Yes/No question.

Imho a Wiki Page would be more suited to track this.

Patch is included in gpg4win now with a comment that it should be obsolete with
newer mingw versions.

With pinentry 0.9 this works in pinentry-gtk under GNU/Linux.

With pinentry 0.8.4 This works in pinentry-qt4 under Windows.

Gpg4win includes a version with paste support since 2.1.0 (I think)

A fix for this has been included in gpg4win 2.2.2.

GnuPG already converted the Output but to CP_ACP instead of the
"GetConsoleOutputCP" which was wrong.

Does this now also work for you? I've only tested it with the Codepage for Germany.

This should be fixed in 2.2.3 (Which will be released soon)

Gpgtar now handles all filenames using the windows 8bit charset. It still does
not support full unicode filenames. For this the fix would have been larger but
at least kleopatra now reacts to gpgtar errors so when you include a File that
can not be handled it will show an error and mention the file that was problematic.

It's not crashing for me with master but its not fixed.

I acidentally ran into this while checking out a windows crash and found the cause:
echo $GPG_AGENT_INFO /run/user/1000/keyring-Lvs93w/gpg:0:1

At least this was my problem and as "Ubuntu" is the platform it is likely that
this was the original problem.

I've commented in the launchpad report.

The error is now handled by Kleopatra:

http://commits.kde.org/kdepim/2a58b4cb452cdb132553c2381ce810bbc2606e55

I'm a bit scared of regressions, though as the Input handling is so
"generalized" in kleo that I don't know if I now broke cases where input errors
are expected :-/

Attached is a screenshot how it looks now with a broken gpgtar version. And
files are no longer deleted as the operation is no longer thought to be successful.

D192: 523_0001-Fix-gpgtar-8-bit-encoding-handling-on-Win32.patch

Werner: Please see attached Patch.

I've tested this with kleopatra and it works now to encrypt a folder which has
special characters in the local code page in filenames. And tested it on the
command line.

This should improve the status quo a lot as full utf16 file names are rarer and
gpgtar / gpg4win is not the only tool which has problems with utf16 filenames ;-)

I did not go for proper unicode support because this would mean:

1. Convert all command line arguments from native to utf8. (Or even to expect

them to be utf-16 *brr*)

2. Expect files-from / stdio file names to be utf8 encoded (and update the callers)
3. Use wide char file io functions. Which would add lots of #ifdefs.

But we would have to discuss if we should do 2. also on non-Windows systems.
Currently gpgtar expects local 8 bit encoding there. So tools using gpgtar would
have to convert their arguments differently for Windows.

Hi,

thanks for reporting this problem.

This has been fixed in the gpg4win sources
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=commit;h=619481b224a9704195c456db74073599d01eac0f

and will be fixed with the next release.

gpgtar correctly returns an exit code != 0 in case an error happens. This exit
code is eaten by kleopatra so the problem that success is reported on error is
on kleos side.

But gpgtar has the encoding problems. From the kleopatra side it looks ok file
names are handed over to gpgtar in local 8 bit encoding and not in utf-8. And
even directly on the command line it fails.

C:\Users\aheinecke\Desktop>"c:\Program Files\GNU\GnuPG\gpgtar.exe" --skip-crypto
--verbose -o c:\Users\aheinecke\Desktop\test.tar -e fäil.txt
gpgtar: error stat-ing `fΣil.txt': The system cannot find the file specified.

The problem is that internally gpgtar treats argument file names as UTF-8 and
even converts the return value from syscalls like findfirstfile to UTF-8 before
opening them. The open uses the utf8 encoded filename and fails as the file
system usually does not use utf8 file names on Windows.

A workaround would be to convert to ACP (CP_ACP (afaik ACP is correct for
filenames)) instead of converting to UTF-8. But this will not work for ?
but as gpgex and kleopatra already fail earlier on "Non 8 bit representable
characters" this should be acceptable for now.

So two fixes need to be done:

• Use system 8 bit encoding for open in gpgtar. -> Should fix most problems
• Handle the return value of gpgtar correctly and escalate it to the user in

kleopatra.

  -> Should make the rest of the problems "uncritical"

I hope to get this done tomorrow evening.

Thanks for reporting this.

This is already part of T1624 although T1624 is confusingly named as it
relates to this problem triggered by gpgex.

We will try to fix it or at least report an error in that case for the next
gpg4win release.

This is a duplicate of T1718

Duplicate of T1718

Got two more reports about this for Windows XP users. So we can safely assume
that this was not just a corner case problem for a broken setup of the Original
Reporter but that it is a real problem.

I'll add a reversion of the commit mentioned fpr 2.2.3

Had a go at this myself. I've attached a patch that checks the gpg-agent version
before migration.

Output when an old version is found:

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: starting migration from earlier GnuPG versions
gpg: error: GnuPG agent version "2.0.22" is too old.
gpg: Please start an updated GnuPG agent.
gpg: migration aborted

Output when gnome-keyring running around:

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: starting migration from earlier GnuPG versions
gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not
interfere with the GnuPG system!
gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.
gpg: migration aborted
gpg: no default secret key: No secret key
gpg: signing failed: No secret key

The error message should also occur in case gpg-agent can not be started at all.
It happens when "GETINFO version" errors. So its generic.

D252: 507_0001-Check-gpg-agent-version-before-2.1-migration.patch

accidentally removed the original reporter from the nosy. Sorry (readded)

I can reproduce this on my test system, if I just create a folder with the name
"földer" Kleopatra / gpg2 /gpgtar don't show an error they just fail silently
and create an empty archive. I guess there is some utf8 to system locale
conversion missing.

As kleopatra offers me the option to "Delete unencrypted files" after encryption
I am marking this as critical as it can lead to data loss.

At least there should be an error so that the removal after the encryption is
not done!

T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.

Not sure what you mean by "It is not useful for that purpose" what do you mean
by "It" and "that" in this context.

With regard to complaints there are reports about this that have been active
nearly all the time since this was broken by 2.2.0:
https://wald.intevation.org/forum/message.php?msg_id=2569&group_id=11

This thread triggered your initial opening of this issue.

I agree that wildcard / multifile it is not very important. But I think we
should fix it as it is a small annoyance and it worked with gpg 2.1.0. That it
stopped working was due to our switch to mingw-w64 and not due to a decision
made by us to disable this. So I would see this as a Bug.

Some more threads about this:
https://wald.intevation.org/forum/forum.php?thread_id=1119&forum_id=21&group_id=11
https://wald.intevation.org/forum/message.php?msg_id=3404

P.S.
Yes I dislike the message boards too but they are surprisingly active.

I disagree, all builtin windows tools do globbing so you expect it on the
command line. And as this is default for software that is built with visual
studio and with some versions of mingw it is more likely to see a software that
supports globbing then not.

With regards to quoting problems. I think that users would prefer some problems
instead of just "no". There is no xargs equivalent in Windows by default and so
you have to fall back to really ugly batch scripts that do this in for loops.

Yes one could argue that those users should use a "real shell" on a "real
system" ;-)

Well, it's part of 2.2.2 now, lets see if we get some feedback on this and maybe
for the next release we can revisit the question again if we should enable this
or not.

Tested this myself again. And I feel comfortable that this is fixed. Still I do
not know why this works now.

Werner can you take a look at the patch I've added for this:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=patches/gnupg2-2.0.26/0001-Enable-wildcard-expansion-with-mingw-w64.patch;h=6c5b9f8b0794cf32ab909c0a340f81377dc3d42f;hb=HEAD

Is this something you would consider including in some form in gnupg or should I
move the patch into the generic gnupg patch directory?

Now for 2.2.2 we've switched to a new dedicated buildsystem with a fully updated
debian wheezy whereas the old buildsystem was a debian unstable snapshot with
the same mingw Version: 2.0.3-1
I could not find an upstream bug or any indication that there was a fix for this.

But with beta-37 of 2.2.2 I was able to use wildcards on the command line.
I am out of my wits why this works now.

Emanuel: can you confirm that wildcards now work on the command line so that we
can mention this in the news and maybe look at integrating the patch into gnupg?
I'd like a different pair of eyes on that behavior. Maybe I've just messed up my
testsystem.

I've commited the patch to gpg4win so it will be part of the 2.2.2 release.

Thanks for summing up the other problems. I've added a reference to this issue
to the "Improve encoding handling" point in the backlog:
http://wiki.gnupg.org/Gpg4win/Wishlist

Thanks for the feedback!

resolved as invalid.

Should be fixed in 1.2.1 (part of gpg4win-2.2.2-beta)

Are you sure that the case sensitivity was the problem here and not the general
Problem that Exchange Addresses were not looked up correctly?

It would be helpful if you could test this with gpgol 1.2.1 (part of
gpg4win-2.2.2-beta) if this is still an issue I'll look into it.

Hi Jon,
can you check this please with the current gpg4win-2.2.2 beta? I've fixed some
object resolution bugs there when Sender / Recipient addresses were not SMTP only.

Thanks

This should be working with gpgOl 1.2.1

As I don't have a test set up I'm setting this to resolved until someone complains.

Pretty picture.

D211: 465_0001-Let-wchar_to_native-convert-to-console-codepage.patch

I've taken a look at this. The problem is that the working conversion code in
jnlib/utf8conv.c is not used on Windows but instead jnlib/w32-gettext.c does
it's own conversion to wchar and then back from wchar to the native codepage
which is simpler and should work.

But the conversion back used the wrong codepage. CP_ACP instead of the codepage
retuned by GetConsoleOutputCP. jnlib/utf8conv.c actually had a comment
explaining why it is neccessary to use GetConsoleOutputCP.

With this changed (see attached patch) I get correct output and can verify /
sign files with non-ascii filenames.

I think gnupg master behaves differently though and I don't have a test setup
for this so the patch is only against STABLE.

Werner any objections into including this patch into GnuPG / Gpg4Win?

I can confirm that this is fixed with libassuan 2.1.2

your debug output points to the same issue that was fixed recently in gpgol
1.2.1 relating to address lookup in Outlook (part of gpg4win-2.2.2-beta)

Please try this version.