Several such bugs have been fixed in the meantime. I can't repeat it anymore.

The context menu of the key manager now has a "refresh key" item.

Yes, it is part of the gpg4win, it is the latest version. 2.2.3 but the last
versions also have the same problem.

From where did you get the gpa.exe - was it part of gpg4win; if so which version?

I've changed the category to gpa, adjusted the topic and version to 2.2.3
As you've already described the problem together with GPA here I think this is
better then opening a new bug.

I'll also no longer call this critical as the original data loss problem
(Encrypting files where one has an umlaut -> kleo thinks its a success and
deletes the original) Should be resolved.

The fix in GPA should be fairly easy. Some conversion from native to utf-8 on
input and utf-8 to native on output. So I'm taking this issue.

Werner: Could you please take a look at the patch for gpgtar. I will probably
propose something quite similar for GPA. Not real unicode support but at least
for 8 bit filenames.

0.9.6 will be release today, thus I close it.

GNOME--

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.

Indeed this has probably been fixed some time ago and the fix is on
0.9.5. But testing again would be useful.

commit d3f20e7883f2fb9e52e487fd516bdc7b9bc695ed
Author: Werner Koch <wk@gnupg.org>
Date: Fri Aug 16 15:18:57 2013 +0200

    w32: Fix crash due to bad conversions of utf-8 in the clipboard.

    * src/gpgmetools.c (dos_to_unix): Remove.  Remove all calls.
    (dump_data_to_clipboard): Return an error code instead of calling
    exit.
    * src/gpaexportclipop.c
    (gpa_export_clipboard_operation_complete_export): Print success
    message only on success.
    --

    The removal of dos_to_unix is possible due to the patch
    https://bugzilla.gnome.org/show_bug.cgi?id=649390 which will go into
    the next Gtk+ 2.24 version.dos_to_unix was anyway not correct because
    it scanned for an embedded nul but it is not guaranteed that it is
    always called with one.

    The other patch which will be helpful is:
    https://bugzilla.gnome.org/show_bug.cgi?id=696232
    (g_utf8_to_utf16() is not guaranteed to succeed. Check the error and
     return if it failed.)

    Gpg4win uses both patches.

    GnuPG-bug-id: 1525

This is likely fixed in 0.9.5 release Sep 1.

Probably needs a retest with gpa 0.9.5

Hi thanks for the report and for trying gpa!

Could you try Gpg4win 2.2.2 (or the version 2.2.3 if it is release).
Thanks!

Meanwhile there are a couple of other fixes in GPA.
It might be useful to do a release soon.

Due to the "in mind" part it took me a while to realize
that your patch is already available ...

Looks good to me and seems to work as expected (on FreeBSD with
gpa 0.9.4, I didn't try with git master). Thanks a lot.

I suspect that (outside the GNU project) ".asc" is more common than
".sig" and would thus sort and check the extensions in alphabetical
order, but obviously it doesn't really matter and I have no data to
support my theory anyway.

D194: 433_0001-Improve-detection-of-detached-signature-files.patch

I have a somewhat different patch in mind. It cleans up the code and adds an
additional test for the signed_file in addition to ".asc".

As it turns out the patch also prevents false negatives when
using the "verify" button on the signature file instead of
the signed file.

A couple of screenshots:
http://www.fabiankeil.de/bilder/screenshots/patched-gpa/

That is standard Unix behaviour and not a bug. Set your umask properly.
GnuPG does the same.

Do you want to turn this into a feature request?

When decrypting files in the file manager window, GPA 0.9.0 creates the plaintext
files with the user's default permissions. On most Linux distributions, this means
the plaintext file is world readable (i.e. umask 0022 -> permissions 0755).

Interesting. Thanks for reporting.

Please do us a favor and describe what you see on the screenshot. It is not
easy to grep over a shreenshot.

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.

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.

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.

Well, were is the bug report?

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.

Fixed in 0.9.4, coming soon.

Tested patches are welcome (against git master of course).

Makese sense.

0.9.3 has been released.