Fixed in 88772dd.

I've revamped pinentry-tty. Instead of displaying y/n, it now uses the first
accelerator or, if there are none, the first alpha numeric character for each
button.

Ctrl+W might not be as useful as Ctrl+U, but I think on Unix that's standard
behavior that can be expected. cryptsetup of LUKS knows it, too.

I wonder how useful this is. When entering your password, you can't see it.
Thus, if you make a mistake are you really able to recover by deleting the last
word? I don't think I could. If werner still thinks it is a good idea, I'll
implement it, but I think it is a waste of time.

The patch seems reasonable. Applied.

perhaps I missed something but...with the command removed how are we able to see
the private keys (esp the details on where they are stored (smartcards)).

Hi Werner,

Thnaks very much for the support.

The version we are using is as below
gpg --version
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,

CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

If we update our libgcrypt 1.4.5 to 1.6.0 will it work for us to decrypt the
PGP file which is encrypted with idea algorithm

There is some weirdness in the code. For example I can't remember why the order
for creating a log is different under riscos. Given that we have not tested
riscos support for ages it might be better to remove it entirely to remove a
source of error.

Creating the trusdb file should only be allowed while holding a lock on it.
That is one of the reasons we use a separate lock file.

The command should be removed because it does not make much sense anymore.
However, it is doumented at many places thus it is not easy to remove.

The main page at bugs.gnupg.org explains that you should ask for updating your
role. I have done that now.

Duplicate of T1931

The patents on IDEA was one of the major reasons to write GnuPG and thus to
avoid IDEA. Meanwhile the IDEA patent expired and Libgcrypt supports it. Thus
if you update to a decent version of Libgcrypt this works for you. Libgcrypt
must be >= 1.6.0. You may also use GnuPG 1.4.14 which also includes IDEA.

On 05/13/2015 11:13 PM, NIIBE Yutaka via BTS wrote:

I think that same bug is in 2.0 and 2.1, too.
I'll try to make minimal reproducible scenario to locate the bug.

Please some one help on this issue. This is little bit critical

On a debian system, i did:

   apt install --no-install-recommends scim scim-gtk-immodule

Here is a transcript of pinentry being invoked: there is additional scim-related
output:

0 dkg@alice:~$ GTK_IM_MODULE=scim pinentry-gtk-2
OK Your orders please
GETPIN
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
GTK Panel of SCIM 1.4.15

Starting SCIM as daemon ...

at this point, no keyboard entry works in the module at all.

This is https://bugs.debian.org/750521

pinentry GTK-2 is still failing to accept any keyboard input when invoked with
GTK_IM_MODULE=scim

Yes, this is fixed. Sorry for forgetting to update this bug. Already noticed your
commits are signed - unfortunately, your commit signing key isn't signed by any other
of your keys, though.

D303: 609_559936.patch

the reporter noted the same problem in 0.9.0, not just 0.7.6.

still, a re-test with 0.9.2 would be useful

sorry, that should be https://bugs.debian.org/581617 instead.

D302: 608_0001-Fix-qt4-pinentry-window-created-in-the-background.patch

Thank you for your time and cooperation.
Your data helps me a lot.
I think that same bug is in 2.0 and 2.1, too.
I'll try to make minimal reproducible scenario to locate the bug.

there is more info in 'gpg-info.txt' inside the tarballs, but for completeness
gpg --version: gpg (GnuPG) 1.4.18
lsb_release -sc: vivid
uname -a: Linux vivid-20150513-125547 3.19.0-16-generic #16-Ubuntu SMP Thu Apr
30 16:09:58 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
filesystem is ext4.

Attaching output of runs.
show-race-output-nostrace.tar.gz
and
show-race-output.tar.gz

both run on fresh 15.04 instance (gpg (GnuPG) 1.4.18).
nostrace version did not use strace. I had to run that in a loop in order to
catch failure. with strace, it fails immediately.

strace version (failed first time):

./show-race.sh

no-strace:
while :; do ../show-race-output/show-race.sh || break; rm -Rf out*; done

Please let us know your filesystem for .gnupg/ directory.
Unfortunately, I couldn't reproduce the bug with your script on my machine.
If possible, could we share the output of the script in your system?

Unfortunately, yes. Still happening with 0.9.2.

This seems to work with gnupg-2.1.4. Thanks!

I forgot to update this issue, 2.1.3 already fixed it. Thanks!

This is about updating the docs. Will be done for 2.1 only.

This reminds me that we don't have a mail keyserver in 2.1 yet. Need to
evaluate whether it will be useful.