gnupg 1.2.1&1.3.1 - BAD output with --with-colons --list-keys for russian uid, not equal --charset utf8 --list-keys

[Yenot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[3rd attempt due to the kerckhoffs.g10code.com DNS problems]

On Wednesday 02 April 2003 12:29 pm, Werner Koch wrote:
> On Tue, 25 Mar 2003 17:53:00 +0300, Sekretnii Yenot said:
> > (Examples: kmail and kgpg.)  These programs are all written with
> > libraries that love raw UTF-8, but GPG is forcing these developers
> > to hand code an extra level of nonstandard decoding.  (Actually, it's
>
> You mean the escaping of certain characters.  This is required because
> you must do this for the delimters (colon and linefeed) and so the
> de-escaping is anyway required.  The escaping is straightforward and
> can be done in place; see gpgme/gpgme/conversion.c for an example.

For whatever reasons, people seem to be missing the decoding
[de-escaping] step.  Even GnuPG itself misses it at times.  Take
the attached key and do "gpg --import public_key.asc", then do
"gpg --list-keys yenot at sec.to". If your locale is set to a UTF-8
variant, you'll see that the first command garbles the UTF-8
characters that are not 7-bit clean, but the second command displays
the entire UID perfectly. [I'm testing this with GnuPG 1.2.1 on
Linux and a locale of en_US.UTF-8.]

Also:
Could someone using a recent version of Kmail verify whether the UID
used to sign this message is being displayed correctly?  If not,
please log this bug at http://bugs.kde.org.  I wanted to log it
myself, but my KDE version 3.0.3 is too old to log a bug report
against.

 - Yenot

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+kr5MP247TY29IxARAqFHAJ4v5qtO6uKf//02Ioa4kbrPLZaIFgCfevlm
OPVS1/ssrw7N5vWi0lthRbQ=
=e7PV
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: public_key.asc
Type: application/pgp-keys
Size: 1848 bytes
Desc: not available
Url : /pipermail/attachments/20030408/b5653040/public_key.bin