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.

Is there still a gnome VFS? This wish is a bit too old. Re-open it if you like.

I did this change for the forthcoming 0.9.3.

Fix pushed.

Regarding the ERR thing: You are right and I wonder why gcc (4.6.3) didn't
caught it.

The malloc + strcpy is a standard pattern. Example;

  struct {
    int flags;
    char name[1];
  } *foo;

  foo = xmalloc (sizeof *foo + strlen (string));
  strcpy (foo->name, string);

will always work correctly. The sizeof returns the length of the
structure which includes 1 byte for name. The strlen computes the
length of string without the terminator. However we alloacted one
extra byte (the name[1]) and thus everything is fine.

The second thing I was wondering about was, is line 71:

x = g_malloc (sizeof *x + strlen (name) );

strlen() won't count the terminating byte whereas strcpy will copy it.

Fixed in master.

I assume this has been fixed.