OK, I'll try that too.

I will try this afternoon.

Also, see if you can reproduce the problem without screen. Thanks.

I tried your screen configuration and I couldn't reproduce the problem.

Perhaps putty is configuring something differently. Can you reproduce the
problem when putty is not used (e.g., directly on the console or ssh'ing from a
GNU/Linux box)?

On Tue, Jun 2, 2015, 11:19 PM Neal Walfield via BTS <gnupg@bugs.g10code.com>
wrote:

Here is my .screenrc

#change the hardstatus settings to give
an window list at the bottom of the
#screen, with the time and date and with
the current window highlighted
hardstatus alwayslastline
hardstatus string '%{= bK}%-Lw%{=
KW}%50>%n%f* %t%{= bK}%+Lw%< %{= kG}%-=%D
%d %M %Y %c:%s%{+b y} %H %l'

deflogin on
shell /usr/bin/bash
vbell on

Thanks for your quick reply. I meant: what program were you running on your
Debian box in screen? I doubt you directly called pinentry. Were you running
mutt? Were you running gpg?

Thanks.

I was using PuTTY 6.4 on Windows 7 64 bit.

I just tried running pinentry-curses under screen on debian in an
xfce4-terminal. (You can run it directly from the command line by running
pinentry-curses and then typing 'getpin'.) I wasn't able to reproduce what I
saw in your screenshot. Also, I saw the proper symbolic characters to paint the
widget's borders (see screenshot).

I've make some changes to pinentry-curses recently. Perhaps you can try that
version (git). If you get the same results, does hitting control-L correctly
repaint the screen?

What program were you running? Perhaps it messed with the terminal settings.

Fixed in b3fd30451a5464b124b0296afbc341cb98b3977c.

Now, we have a patch to fix in the Debian bug tracker.

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.

(funny due date removed)

Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.

I have fixed it for the gca functions percent and percent+ but won't do it in
the generic percent_exacpe C function. Changing the latter may introduce
regressions.

Fixed for 2.0 and 2.1.

As I wrote to #712744, distribution nowadays is conservative enough for its
default kernel settings, and it doesn't require each application to have special
settings.

I think that we will be able to close this soon.

Thanks. Fixed with commit dc10d46.

The attached patch fixes hkps: hostname verification and makes
hkps: use SNI correctly.

The patch is against GnuPG 2.1.2. It has been tested successfully against
hkps://hkps.pool.sks-keyservers.net on FreeBSD 10.1 using GnuTLS 3.2.21 and the
2.1 setup instructions at https://sks-keyservers.net/overview-of-pools.php#pool_hkps

D275: 586_poolname_and_SNI.patch

Should be fixed by commit 017c6f8fba9ae141a46084d6961ba60c4230f97a
on 2014-06-24.

D281: 541_0001-Fix-a-problem-with-select-and-high-fds.patch

Given that it seems not easy to reproduce this bug can you please test
commit 8adb5ff or the attsched patch to see whether this helps.

If it does not help, can you do a gpg build with debug symbols and run your case
again. If possible attach a debugger for a backtrace or produce it with a dump file.

Well, that is quite possible. I have seen other reports about this. I have not
yet come around to look at the hkps bugs.

Yes, this is the case for a very long time. I also won't call this a
bug.

There is no way to protect an update by a lock without having write
permissions to the same directory. Well, one could setup a second
file system hierarchy below /var/run and use that for the locking
file. However, this assume that all process accessing the files are
on the local machine. One of the reasons why we can't use a locking
API are remotely mounted file systems. See the comments in
common/dotlock.c .

And yes, we need lock the file even if the local process as no write
permissions to the directory - other processes may have and the
reading process may thus read garbage.

By using --lock-never you assert that there is no other processing
writing to the gpg data files. Thus using this is the Right Thing.

I assume this is related to T1630 which has been fixed

oh, and this appears to be the case for 1.4.x, 2.0.x, and 2.1.x

That link to the debian bts is a little wacky, somehow roundup is attaching the
comma to the end of it. it should be: https://bugs.debian.org/771976

dkg developed a reasonsable patch which will be included in the next 1.4 version.

No bug and I already set this bug to resolved.

Judging by the lack of reply, I assume that this bug won't be fixed, correct?

I read that. It says that RSA-2048 keys are going to be safe until 2030. Doesn't
sound like a lot to me... Considering the average human lifespan, I could be
around until 2070. So, nope, not enough.
If all the emails I sent till now have been intercepted and stored (which seems
to be the case according to Snowden), using a RSA-2048 key simply means that all
my private correspondence is going to be public (or at least accessible) in 16
years time. Now, the only thing I'm asking is to raise the amount of secure
memory allocated by GnuPG to 128k to let people use key sizes up to 16384,
something that was even allowed by the keygen itself.

Please read the FAQ starting with
https://gnupg.org/faq/gnupg-faq.html#default_rsa2048

By the way, is this all bullshit?
AES-256 == RSA-15360 / DSA-15360 (NIST)
http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2006-03/E_Barker-
March2006-ISPAB.pdf

AES=256 == RSA-15424 / DSA-15424 (ECRYPT2)
http://www.ecrypt.eu.org/documents/D.SPA.20.pdf

Ok, got it. So I can just throw away my key and make a new one?
Fantastic. Thanks a lot.
Sounds a lot like "640K ought to be enough for anybody".
So long, and thanks for all the good work on GnuPG (seriously).

No.

Please read the FAQ on key sizes and if you have a lot of time the countless
discussions on gnupg-users. No, you are not paranoid but you are tuning the
wrong parameters. IT will never be a standard. There will never be any keys
larger than 4k RSA in real use.

Yes, I know how to change the code and make it work on _my_ machine.
There is the tiny problem that everyone else has to do it, too.
Can we make that change the default? I don't see a big problem in using 64k or
128k instead of 32k of secure memory.
By the way, 16k of key size is ridiculous now, but it's going to be kind of
standard in the not so distant future. Or am I too paranoid? :)
Just trying to have a GnuPG key which is future-proof, also taking in
consideration the possible use of quantum computers in the future.

Sorry, there is a limit on the size of secret keys which depends on
several factors. We allow for way longer keys than can be generated
by gpg to take the fuzziness in account, but only up to some limit.
You are on your own if you want to use ridiculous long keys.

Hint: You may increase the size of the secure memory my changing the
line

    /* initialize the secure memory. */
    got_secmem=secmem_init( 32768 );

in g10/gpg.c. Use a larger value there and it will work.

also fixed in 2.0

Done for 2.1 with commit 03018ef

Also applied to master.