For some chiffre texts (I got 4 today, but all have secret content, so I cannot
publish them) the decoding from clipboard fails with error message in attachment.
Sttoring the same content in a file and decoding from file works fine.
For some chiffre texts (I got 4 today, but all have secret content, so I cannot
publish them) the decoding from clipboard fails with error message in attachment.
Sttoring the same content in a file and decoding from file works fine.
The content probably contains umlauts or accented characters for example in the
comment line or the text before the BEGIN PGP lines. We currently require the
clipboard to have valid utf-8 (or ascii) characters.
We will check whether we can detect the encoding and auto convert it.
According to the error message this seems to be well and the message is probably
the result of a test for an valid UTF-8 char, but the stored file was creadted
from the same copy step via a second paste in the same step.
Perhaps you start to count at a wrong position after the clipboard header.
Stored files can be in any encoding, as they are not displayed, so
interpretation is up to the user. But for a displayed string, the encoding matters.
It is possible to guess encodings (enca/libenca), and in practice it probably
works out ok. From a security point of view though, not negotiating an
interpretation of the characters transmitted through the secure channel is a bit
of a concern! Of course this goes way beyond the character encoding issue.
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