1 month, and not even a single comment. Am I the ONLY person on earth with this
problem, or the ONLY 1 who cares?

Fix will go into 2.0.21. Thanks.

Well, gcry_check_version is not called at all. The fix will go into 2.0.21 to
be released today.

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.

That is not a bug. During import GPG removes invalid or unneeded parts,
reorders packets to fix bugs introduced by some older keyservers, and so on.
During export some other stuff might be removed depending on certain GPG options.

If you want to learn about the details please write to the gnupg-users mailing list.

Hm. The process disappears after some time. Maybe it just needs some time to
finish. Maybe not a bug anymore. Please take a look at it yourself.

Can you please take a look at it again? If I compile long_genkey.c and run it
via ./long_genkey async it leaves a process behind, which should better be killed:

ps aux | grep gpg
dl 7577 7.0 0.0 24416 1924 pts/2 SL 22:05 0:00 gpg
--enable-special-filenames --use-agent --batch --no-sk-comment --lc-messages
de_DE.utf8 --lc-ctype de_DE.utf8 --status-fd 4 --no-tty --charset utf8
--enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm
--gen-key -- -&5

Here are the example keys:

http://pastebin.com/cseQ0z8j

Has GPA been installed by gpg4win? If so, what version of gpg4win?
If you built it yourself, I need the gpgme version you are using.

I can't replicate your problem. You need to make sure that gpg is able to
connect the agent. This either done by setting GPG_AGENT_INFO properly or by
starting the agent like

cd myhomedir
GNUPGHOME=$(pwd) gpg-agent --daemon /bin/sh

and then run gpg in that shell.

GPA was missing features to import and export X.509 certs. I added this with
commit 6742525. This will show show up in 0.9.5 and in any case in a gpg4win
beta release we plan for Monday. Note, that you need the latest gpgme from GIT
for the import feature.

Can you please at least acknowledge whether these are bugs or not?

Fixed for 2.0 with commit 110b52f.

Thanks.

Please describe your problem in detail.

Well, were is the bug report?

Please check that no other software conflicts with gpg. For example some virus
detection tools may block the IPC. The Enigmail folks should know about such
problems.

Pointing to some discussion on a forum is not a replacement for a bug report.
Please be so kind and write a proper bug report without referring to external
sources. Thanks.

Problem seems solved; reason very likely found.

After years of taking a break from GPG, I took the work up again. First I
upgraded to GPG version 1.4.14 (the currently latest version). Then, in
reviewing my previous work, I found that in the interprocess dialog between my
program and gpg.exe I had been sloppy and had caused race conditions. In the
process of improving these dialogs, the described problem disappeared, i.e. did
not come up again despite some intense testing. I hope it stays that way!

Thus, although I cannot put my finger on "the one" code change that did it, I
tend to think now that the problem has been mine from the beginning, namely that
I had programmed race conditions. The intermittent nature of the original
problem supports this assumption.

I apologize for any inconvenience that has caused.

OK. The case is closed.
In the Kleopatra screens it is always the primary key that is visible. There was
no expiration date on that key. Looking into the properties of the key, I noticed
that there was an expiration date on the subkey.
So I could sign with the key, but not encrypt.

It seems that one of your keys is not capable of encryption or expired. Thus it
is not be listed for encryption tasks.

Here is some additional information which may be helpful:

(1) Output of Events Viewer

Faulting application name: Explorer.EXE, version: 6.1.7601.17567, time stamp:
0x4d672ee4
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc0000374
Fault offset: 0x00000000000c40f2
Faulting process id: 0x1934
Faulting application start time: 0x01ce82dff437854c
Faulting application path: C:\Windows\Explorer.EXE
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 9f753f17-eee3-11e2-9f80-0016d33c76d0

I hope this is helpful. Thank you.

Hmm... wondering then however, why implement different behavior for --status-fd
set?

What is the threat model for this? If you are able to ptrace a process you can
do all other kind of stuff, like replacing gpg with your own code. If the box
has been taken over, we are in game-over state.

Disabling core dumps is a different issue because a core dump leaves traces of
the process on the disk.

Actually this is a feature. Ever tried to work with a bunch of messages all
encrypted to many hidden recipients?

FWIW, recall that PGP is broken as it did not (does not?) use UTF8 but assumes
everything is ASCII. Thus we sometimes find weird charset conversion. GPA has
a heuristic to at least detect Latin-1

The web build systems is entirely broken and not maintainable. I started a
conversion to org-mode to ease maintenance in the fure. But well, only started.

We released a new Beta yesterday and due to a build glich we will update that
today. Thus I close this bug.

The mailman passwords are by design weak and the web page explictly mentions
that you should not use a valuable password. The admin can anyway see everything.

I maintain scute in Debian. It works for me for years.
I suspect it was build time issue.

The option --default-cert-level is described in the manual.
Thus, this bug report is about web.
Changing "category" from gnupg to gpgweb.

Reporter's intention would be:
Given a public key with user id="", importing that key fails.

Most DLLS and exe files have versioninfos - some where not instantly displayed

due to missing language information.

Yes, I'm also used to discover that "the" version info of an assembly must be
EN-US (or default) regardless of the what I wanted to.

I'm now subscriber to the mailing list, although I hate these mailman mailing
lists, because I found out that they're storing passwords in plaintext in their
database (isn't that weird when developing strong encryption tools?)

IIUC, this bug report were talking aboug
http://www.gnupg.org/download/release_notes.en.html

At that time (2008-12-08), there were 1.4.9 and 2.0.9, but the page didn't have
information of those version. There is no information about 1.4.9 and 2.0.9,
still now.

I think that Andrew's name in Chinese in UTF-8 cannot be interpreted as iso8859-1,
it goes as is, but usually it is interpreted as iso8859-1 as a fallback.

If you are sure it's utf-8 encoded, you can use --utf8-strings option.

This bug is still there in 2.0.20.
It would be better to add following line in main of gpgv.c.

gcry_control (GCRYCTL_INITIALIZATION_FINISHED, NULL);

I think that original reporter's intention is to prevent attaching by ptrace.
By PR_SET_DUMPABLE disabled, ptrace PTRACE_ATTACH won't work any more.
This would be better if we care about kernel compatibility.
In http://bugs.debian.org/714107, I found that setrlimit64 doesn't work reliably
for 2.6.34 or older. PR_SET_DUMPABLE seems to work for even 2.4.x.

Fixed in 212a325d428e0ab5c51c42a3ea33efb21ad1f79f

I just backported the new ssh-agent code from master to the 2.0 branch. Thus
2.0.21 will have this support.

Last week I posted a revamped version og GpgEX 64 and 32 bit to the gnupg-users
mailing list. You may want to try that one. It is also possible to build a
complete new Gpg4win installer with gpgex 32 and 64 bit. We will release a beta
next week.

Most DLLS and exe files have versioninfos - some where not instantly displayed
due to missing language information.