But the secret subkeys are not used. Or well, the keyflags should be taken from
the public key. That might not always be the case - in particular not if you
re-create the public key from the secret key.

You can of course repair it using 2.1 because there --export-secret-key takes
the public key and only adds the secret parameters.

What's not clear to me if it is possible to recover a private key that is
damaged this way? If you change expiration with 1.4, the self-signatures are
lost and some key flags are changed. Is it possible to recover from that? That
is the problem I'm concerned with -- if it isn't possible to recover, it seems
people end up with damaged secret subkeys after changing expiration date on a
subkey with gnupg 1.4/2.0.

No, he can't. The data received from a keyserver is by defintion unreliable.
It may be any kind of trash. gpg takes care of ensuring that the data (i.e. the
keys) are consistent.

There has been a long and heated debate over this recently on whether the
additional check introduced with 1.4.18 is at all useful. In any case what you
requested is in all recent versions of gpg. I thus close this bug.

T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.

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

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:

1. incorrect display of GPG 2 output translated into another language (also

reported in Issue 1373 and Issue 1674): fixed by your patch;

2. 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

3. incorrect display of filenames with non ASCII characters (also in Issue 1409)

4. 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)

5. 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 :-)

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.

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.

Backported to 1.4. It has also been applied to master some time ago.

Hello Werner,

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.

So what is your problem now? Mistaken report - shall I close it?

sorry can't delete

Fixed with commit 9d89564 for 1.4.16.

Thanks for reporting.

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.

Here are the example keys:

http://pastebin.com/cseQ0z8j

In order to work around this potential bug I do the following at the moment:

1. Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.

2. 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:

1. Create a certify-only RSA4096 primary key.

2. Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}

3. Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --

export 0xEEE9979BE8C80E95

4. Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --

export 0xB6BF97893ACA0C17

5. Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95

6. Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt

7. Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}

8. 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.

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.

Fixed for 1.4.13 (e3e5406)

Fixed for 2.0.19 (8b9fb19).

thanks for your answer, ill give it a try with a newer version.

1.4.5 is pretty old. Please try 1.4.11 and check whether the bug persists.

Solved problem, please close.

Mailing List?, Ok.

ok, done

Please ask on the ML for advise.

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.

*checks*/encrypt.test.logs, I suppose?

What is the content of tests/encrypt.test.log ?