T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 12 2014
Aug 26 2014
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
Aug 25 2014
Thanks Andre for the patch!
I managed to build gpg4win with the patch added and I verified that it seems to
solve the problem reported by me and also in Issues 1373 and 1674!
But I'd like to summarize the problems related to the charset / codepage on MS
Windows of which I am aware, as a reminder:
- incorrect display of GPG 2 output translated into another language (also
reported in Issue 1373 and Issue 1674): fixed by your patch;
- passphrases (both for secret keys and symmetrical encryption) with non ASCII
characters set using GPG 1.4.18 are considered not valid using GPG 2.0.26 and
vice versa
- incorrect display of filenames with non ASCII characters (also in Issue 1409)
- GPG 2.0.26 and 1.4.18 ignore or weirdly comply with --utf8-strings, --no-
utf8-strings or --charset options for utf-8 encoding of encrypted filenames (see
Issue 1409)
- charset weirdness searching keyserver for some non-ASCII user IDs under non-
UTF-8 locales (see Issue 1514 - although relates to Linux it seems to occur also
on Windows, both CLI and GPA but not Kleopatra)
Hope this will help to improve the great GnuPG :-)
Jun 27 2014
Just for my information, do you have done some tests for GnuPG2 on boot (because existant script are based on gpg) ?
okay.
Hello Werner,
I don't think that it is worth the trouble. A pinpad reader make most sense on
desktop machines and there we have 2.x. 1.4 is maintained for use on servers
where card support is anyway hard to operate.
I can confirm to you as I've write last time, but this time with new gnupg2 (2.0.24)
and gnupg (1.4.16) version, than Vega reader works fine with gpg-agent, but failed without it.
Jun 26 2014
In 2.1.x (development), scdaemon and its pinpad support has been improved
(including name change from "keypad" support), and it's backported to 2.0.x.
However, it is not backported to 1.4.x. For gpg of 1.4.x, it only works when
you use gpg-agent and scdaemon of 2.?.x.
Some fixes (such as PC/SC support for MacOS) are backported to 1.4.x, though.
For Covadis Vega-Alpha, we would need to backport pinpad support improvement, as
well as CCID driver support improvement (for no auto configuration feature).
Changes are not trivial to merge, I don't know if it's worth for 1.4.x.
Jun 23 2014
Backported to 1.4. It has also been applied to master some time ago.
Jun 7 2014
Hello Werner,
Jun 6 2014
Jun 2 2014
Jan 28 2014
Jan 8 2014
Jan 5 2014
Yes, please close it. Don't know how to answer your mail at the web interface. Sorry for these mistaken reports – I didn't know and I wrote them too fast. I'll try not to
do this in the future.
Jan 1 2014
So what is your problem now? Mistaken report - shall I close it?
Dec 19 2013
sorry can't delete
Dec 16 2013
Oct 15 2013
Oct 11 2013
Fixed with commit 9d89564 for 1.4.16.
Thanks for reporting.
Oct 4 2013
Aug 13 2013
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.
Aug 10 2013
Here are the example keys:
May 18 2013
In order to work around this potential bug I do the following at the moment:
- Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.
- Restore: (a) Import the ASCII-armored *public* key together with its subkeys. (b) Import the ASCII-armored *secret* key together with its subkeys.
The actions [1.(b)] and [2.(a)] should not be necessary if there was not this
potential bug.
I further tried to find the action that causes the potential bug with an another
test key as follows:
- Create a certify-only RSA4096 primary key.
- Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}
- Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --
export 0xEEE9979BE8C80E95
- Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --
export 0xB6BF97893ACA0C17
- Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95
- Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt
- Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}
- Repeat action 1. to 7. by: (a) Adding a sign-only RSA4096 subkey. (b) Adding a encrypt-only RSA4096 subkey. (c) Change the expiry date of the encrypt-only RSA4096 subkey.
ERROR: *Changing the expiry date*, exporting, purging, importing the primary key
with its 2 subkeys makes the first sign-only RSA4096 subkey disappear from the
pubring.gpg file but not from the secring.gpg file.
Apr 18 2013
That is okay. One reason for this is the encoding of big integer numbers; if
such a randomly generated number has the high bit set, a leading zero needs to
be inserted.
Apr 17 2013
Nov 8 2012
Fixed for 1.4.13 (e3e5406)
Mar 26 2012
Fixed for 2.0.19 (8b9fb19).
Oct 12 2011
thanks for your answer, ill give it a try with a newer version.
Oct 11 2011
1.4.5 is pretty old. Please try 1.4.11 and check whether the bug persists.
Sep 30 2011
Jul 1 2011
Jun 28 2011
Jun 24 2011
Jul 20 2010
Solved problem, please close.
Jul 19 2010
Mailing List?, Ok.
ok, done
Please ask on the ML for advise.
Jul 17 2010
Mar 2 2009
Jan 28 2009
The build is broken. We had a report on the mailing list from SuSE and they
figured that the SuSE Toolchain is broken. Thus you need to update your OS - I
am not sure whether this is available. Please check the gnupg-users or
gnupg-devel mailing lists for further info.
Jan 26 2009
*checks*/encrypt.test.logs, I suppose?
What is the content of tests/encrypt.test.log ?