I've checked that 2.1.10 still has the problem. So back to you.

You can ping me directly if you need any debug logs or so.

gniibe: its not one failure in 248. It was 248 failures in 248 tries...

werner: I had to downgrade to have a working system. I hope I'll find time to
reproduce this this week

It seems to be base64:

% ssh -V
OpenSSH_7.1p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E md5 -q
playfair.gnupg.org RSA MD5:cc:dd:46:8e:ef:3d:d9:34:97:f8:b8:5a:59:51:80:4a
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E sha256 -q
playfair.gnupg.org RSA SHA256:KCh034SD0rMKqCkJbdH2wx354s1278tqt9F+xb5cidg

Thank you for the bug report. The ratio of 1 failure among 248 made me a great
hint to locate the bug.

I think that it is fingerprint computation bug, which is fixed here:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d40975cbe8ff86fcc4a1b4963fdffc66ddee85ce

Thanks for helping keep track of all these issues.

Yes this only fixes the problem that has already been fixed in the last Gpg4win
Versions. So that this will be fixed in future gnupg-2.1 versions.

Still to help us better seperate the problems I would like to close this as for
me this bug was about "Wrong encoding in a localized version".

• the more critical "passphrase with non ASCII characters" problem (as reported

only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?

I actually overlooked this in this issue. Can you please open another issue for
that. And add me to the Nosy.

• the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-

strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)

If this problem was still existing with gpg4win this is still a problem.

• the "charset weirdness searching keyserver for some non-ASCII user IDs under

non-UTF-8 locales" (as reported in Issue 1514).

This appears not to be windows specific. Also I think this works except for
cases where the Key in question is problematic. If I search on windows for
emanuel@intevation.de I get the correct Umlauts shown. Might be a Problem though
for characters that are unrepresentable in the 8 Bit codepage.

I'll try to look into that.

It sounds great!

So this patch, as the previous one, solves the "incorrect display of GPG 2
output translated into another language" (as reported here and previously also
in Issue 1373 and Issue 1674).

Does this patch solve also the "incorrect display of filenames with non ASCII
characters" (as reported here and previously also in Issue 1409)?

By the way, as I understand, this patch doesn't fix:

• the more critical "passphrase with non ASCII characters" problem (as reported

only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?

• the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-

strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)

• the "charset weirdness searching keyserver for some non-ASCII user IDs under

non-UTF-8 locales" (as reported in Issue 1514).

Please do not open another bug but comment on the very same bug you posted a few
days ago (issue2166).

In any case, this is a question and not appropriate for a bug tracker. Use one
of the mailing lists for such questions or see https://gnupg.org/service.html
for commercial support offers.

Duplicate of T2166

After some more discussion and testing in the development jabber channel werner
agreed to include this patch. Pushed to libgpg-error with 823e858. So this will
hopefully be part of the first gnupg modern release that will include localization.

D210: 737_0001-Fix-windows-8bit-encoding-conversion.patch

Updated Patch against libgpg-error where this code now lives.

Please apply this patch or something similiar.

The problem I can see is that with this code in libgpg-error now GUI
applications may use it which want to get "GUI Native".

Probably better to introduce a new function "wchar_to_console" ? And use it from
GnuPG. Does GPA use that conversion function?

Might be a good time for this now where gnupg master already depends on new
symbols in libgpg-error.

Thank you for your testing.

Your change is pushed with my comment:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d1a97585c5e73fbc7d4cf90e38f76ffc5aea305f

I'll backport this to GnuPG 2.0.

Here's the logfile with all the errors (guru debug level) vanilla 2.1.10

After some time spending fighting with the build tools of gnupg (cross compile
for windows under debian) I managed to build the installer with my patched
file.

Most important: The most common error thrown is the 0x8010001e
(E_SERVICE_STOPPED) This is the important one. The other error 0x8010001d
(E_NO_SERVICE) is only thrown in the transition from ok to stopped. So only
sometimes.

This was my process:

git clone git://git.gnupg.org/gnupg.git
cd gnupg
git checkout tags/gnupg-2.1.10
./autogen.sh
cat ../0001-scd-Fix-removal-of-unplugged-usb-readers.patch | patch -p1
sed -i -e 's/^SELFCHECK=1/SELFCHECK=0/' build-aux/speedo.mk
make -f build-aux/speedo.mk w32-installer

I've created new logfiles (vanilla 2.1.10 und patched 2.1.10) to show the
difference and confirm that it'S actually working now :-)

I'm okay with signing off the commit. I can test this for Windows 8.1 or 10,
my only problem is that I'm not able to compile gpg for windows right now. Or
are there instructions somewhere on how to achieve this?

Thank you again.

I think that Windows 8 (and later) changed the PC/SC service. The service is
only available when smartcard is there, and after the removal, it returns
PCSC_E_NO_SERVICE error. This is not expected for current code.

I'm applying your patch with my comment like above. Do you agree to put the
line in the commit log?:

   Signed-off-by: Daniel Hoffend <dh@dotlan.net>

I don't have Windows 8 machine. So, I leave this issue as testing.

Closing, I assume it's the same bug of 2112, which was fixed.

No, I just installed version 2.1.10 (which included your mentioned fix). But the
error still applies.

In my case the smartcard reader never gets closed, cause the error thrown by the
pcsc/scd gets only mapped to a general_error which does not result in
removing/closing the reader interface.

I've the feeling that we've to take a closer look at the errors thrown (at least
those 2 in my patch). Maybe there're even more possible events.

If you like I can upload the debug log of scdaemon 2.1.10 ... (if that helps).

Somehow I don't have any issues when running linux, this bug applies to windows
only atm. Maybe it's just that windows is throwing different errors or events
compared to linux.

Thank you for the bug report with log.

It could be related to the bug which was just fixed:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=f42c50dbf00c2e6298ca6830cbe6d36805fa54a3

I'm backporting this to 2.0.x.

Some more infos:

https://www.openkeychain.org/faq/#importing-your-own-key-from-gnupg-fails
says that this is a problem for a number of people.

Werner told me that porting the fix back would mean to basically
migrate 2.0 to 2.1, which is useless because 2.1 is already 2.1.

Another possibility would be to change --export to mix public keys (certs)
with secret keys. This would create other problems and thus is not
adviable for a stable version.

So I think this is "won't fix" because it (technically) does not make
sense to fix in 1.4 or 2.0. Solutions: Use 2.1 or wait for 2.2.
As importing implementation: Be tolerant for this problem man use the cert
information if you can.

The keyserver preferences are major privacy problem. They should not be used
and in fact they are ignored in Tor mode. Thus we should not put too much work
in fixing this wish.

6.7 still shows MD5 fingerprints thus switching won't be easy. Does the SHA-256
fingerprint use Base32? If that is the case it might be a serious UX problem
because most people are used to look for colon separated hex digits.

Related issue: #1166.

Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:

Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is
given.

This will also help us address issue #1827.

After looking at the gnupg 2.0 branch I would say the patch could be applied
to the 2.0 and 2.1 branch to fix the issue in both branches stable/modern
since both version are affected (tested with 2.1.9 and 2.0.29 from gpg2win)

I was looking a bit deeper into the gnupg code and debug messages. As soon as I
plug out the yubikey the usb smartcard reader including the internal smartcard
is no longer available. GnuPG is sending the following messages:

1. this call is still okay 2015-12-06 23:20:31 scdaemon[10940] DBG: enter: apdu_get_status: slot=0

hang=0

2015-12-06 23:20:31 scdaemon[10940] DBG: leave: apdu_get_status => sw=0x0

status=7 changecnt=1

1. here the card is no longer available 2015-12-06 23:20:31 scdaemon[10940] DBG: enter: apdu_get_status: slot=0

hang=0

2015-12-06 23:20:31 scdaemon[10940] pcsc_get_status_change failed: no

service (0x8010001d)

2015-12-06 23:20:31 scdaemon[10940] DBG: leave: apdu_get_status =>

sw=0x1000b status=7 changecnt=1

Error Message 0x8010001d == SCARD_E_NO_SERVICE (The Smart card resource manager
is not running.)
https://pcsclite.alioth.debian.org/api/group__ErrorCodes.html#gad4729ab109ff490
285d2ad881c04bee8

Now there's an internal mapping happing from 0x8010001d to sw=0x1000b
http://git.gnupg.org/cgi-bin/gitweb.cgi?
p=gnupg.git;a=blob;f=scd/apdu.c;h=95a25611b7ff46c87e2e888643bec0a10454f894;hb=H
EAD#l899

The SCD internal resulting error is 0x1000b means SW_HOST_GENERAL_ERROR which
is the default error if nothing else has matched yet.

The next lines in the logfiles are showing a different pcsc error code.

2015-12-06 23:20:32 scdaemon[10940] DBG: enter: apdu_get_status: slot=0

hang=0

2015-12-06 23:20:32 scdaemon[10940] pcsc_get_status_change failed: service

stopped (0x8010001e)

2015-12-06 23:20:32 scdaemon[10940] DBG: leave: apdu_get_status =>

sw=0x1000b status=7 changecnt=1

Error Message 0x8010001d == SCARD_E_SERVICE_STOPPED (The Smart card resource
manager has shut down.)
https://pcsclite.alioth.debian.org/api/group__ErrorCodes.html#ga262c34297ab1b65
db1c9516ccc0dd9a0

The pcsc error code is still mapped to the generic error code (0x1000b)

--

possible resolution: I've no clue if the error codes 0x8010001d or 0x8010001e
are thrown in different scenarios. But if we would map those 2 messages to the
internal SW_HOST_NO_READER error the scdaemon would like remove the (likely
disconnected usb) reader from the current list, resulting in freeing up the
used card.

I can't verify this idea cause I'm not able to compile gnupg under windows but
I've attached a solution patch in this ticket

D339: 732_0001-scd-Fix-removal-of-unplugged-usb-readers.patch

I generalized the ssh key fingerprinting code so that we can select the digest algorithm.

Now I'm a little unsure how to proceed. We can easily include both the MD5 and the SHA256 digest
in the sshcontrol file. But what shall we use for expanding '%F' in key descriptions? If we
transition too soon or too late, users might not recognize their key. Displaying both surely is
too verbose. We could make it configurable, or at least a compile time option.

What do you think?

Err, fixed in 6ac57a48.

Fixed in

Fixed in a8308ba5.

% g10/gpg2 --keyserver hkp://keyring.debian.org --search-keys dkg
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: error searching keyserver: Not implemented
gpg: keyserver search failed: Not implemented

Well ... the udev can only be a workaround. Killing the scdaemon from the
outside is not the correct way to handle this issue.

scdaemon should realize it itself that it's connection to the smartcard has
been stopped/killed/canceled/disconnected (whatever) and kill/reset and
restart it's internal process leading to removing the previously loaded card
from the memory.

There should be no need for an outside trigger.

I tested this with a fresh windows10 (which has never seen a yubikey
before). I installed gnupg 2.1.9 binaries and gnupg was able to speak with
the card with no additional drivers needed. (the problem with disconnecting
the card still occours).

And without the need of special drivers there should be no need for any
special rules to be applied.

The problem here is that the hkp client code folds all http status codes other
than 200 and 3xx into GPG_ERR_NO_DATA. This is also a problem for issue #1038.

In the meantime, a workaround is to add an udev rule to scdaemon whenever the
Yubikey is plugged in:
https://github.com/Yubico/yubikey-personalization/issues/36 . I guess it doesn't
work on Windows, though.

OK, so things have changed regarding how this is handled since 2.1. That’s
probably why people like me think it’s still bogus, because behind the true bug
there was also another underlying change.

I can confirm it now works once correctly configured. Thanks for your help.

This, 2123 and 2130 can be closed I think.

On Wed, Dec 02, 2015 at 12:55:23PM +0000, Justus Winter via BTS wrote:

Justus Winter <justus@g10code.com> added the comment:

I can reproduce this without the proper configuration described in https://sks-
keyservers.net/overview-of-pools.php#pool_hkps:

I'm not sure, I reverted said change, and it still works for me:

% echo -e "KEYSERVER hkp://ipv6.pool.sks-keyservers.net/\nKS_SEARCH CADE3658\n"

dirmngr[10105.0]: marking host '[2a01:4f8:192:f5::3]' as dead
dirmngr[10105.0]: marking host '[2001:41d0:2:a8b4::10]' as dead
dirmngr[10105.0]: marking host '[2001:67c:2050:1000::3:4]' as dead
dirmngr[10105.0]: marking host 'hufu.ki.iif.hu' as dead

The log clearly states the problem:

2015-10-09 10:27:37 dirmngr[2516.0] TLS verification of peer failed: The
certificate is NOT trusted. The certificate issuer is unknown.

Please see https://sks-keyservers.net/overview-of-pools.php#pool_hkps for how to
configure gpg properly. With the CA for the pool, this works as expected.
(remember to kill the old dirmngr daemon):

% gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys
5EE1DBA789C809CB
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 89C809CB: public key "git-annex distribution signing key (for Joey
Hess) <id@joeyh.name>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Total number processed: 1
gpg: imported: 1

I can reproduce this without the proper configuration described in https://sks-
keyservers.net/overview-of-pools.php#pool_hkps:

% :> /home/teythoon/repos/g10/local/gnupghome/dirmngr.conf
% gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error

But with it, it seems to work fine. Remember to kill the old daemon first:

% echo hkp-cacert /home/teythoon/repos/g10/sks-keyservers.netCA.pem >
/home/teythoon/repos/g10/local/gnupghome/dirmngr.conf
% pkill dirmngr
% gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: data source: https://jarvis.alpha-labs.net:443
(1) NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>

          2048 bit RSA key 33BD3F06, created: 2014-10-29, expires: 2016-10-28

You can talk to the dirmngr directly like this:

% echo -e "KEYSERVER hkps://hkps.pool.sks-keyservers.net\nKS_SEARCH 2071B08A33BD3F06\n" | dirmngr

If this still does not work for you, please paste the output of the above invocation.

'gpg-zip' is being phased out. It will be shipped with gpg-classic, and dropped
from gpg-modern. Furthermore, I just checked that we no longer install gpg-
zip.1.

UPDATE: The latest gpg on an AIX box that I could get my hands on does not work
at all, so until that problem is resolved I cannot really test further.

When we invoke gpgme a process just hangs, but as far as we can tell from the
strace, gpg is busy closing file descriptors in the entire file descriptor
range! If we limit the file descriptor range to a smaller number (by, say,
"limit descriptors 4096 ; limit -h descriptors 4096"), we get a fast failure.

The gpg versions we have installed are 2.0.26 and 1.4.18. It seems that the
pinentry program never even gets invoked. Attached is a program you can test with.

Right, or for example to re-encrypt a message to a workmate.

I have no examples. However I have seen too many scripts using gpg in often
very strange ways. Thus I always hesitate to change anything even if it is
clearly stated that this is not a documented interface.

People often hack something, it works for them, and they continue with other
work. Years later things break and nobody is left knowing what the code
actually does. Not good but that is how things are.

There is no guarantee how long the output will be. Several factors influence
this. For example the compression or removed leading zero bytes in encrypted
random session keys can have this effect.

If you have more questions about this, please direct them to one of the mailing
lists.