Well, here's my fix. Using this neat little program I downloaded called
Resource Hacker, I edited the buttons on the dialog box so that they would
be big enough to display the messages needed. Realizing that pinentry.exe
and pinentry-w32.exe were identical files (checking them in a hex editor
with file comparison function showed them to be exactly the same), I just
copied my edited version of pinentry.exe and renamed the copy as
pinentry-w32.exe. I have put both of them in a zip file called
pinentry.zip, and have attached this zip file to this email. Feel free to
distribute this on the official GPG4Win website. Note that the file name of
the attachment is "piz" not "zip", so before you extract its contents (for
use, or posting on your website) you will need to rename it from "piz" back
to "zip". I had to rename it from "zip" to "piz" because otherwise Gmail's
mail server scans inside the zip file and then for blocks it because it
detects exe files (and exe files are a format that can potentially harbor
malware). Even though this has no malware (as you can see by scanning it
with a virus scanner), Google's mail server takes extra precautions by
refusing to allow sending of executable files or even archive files that
contain executable files.

As far as I know, GPG4Win is a compiling/linking of GPG to be Windows
compatible, which means that the code was already altered to work with
Windows. Therefore native Windows code is already in use in the GPG4Win
variant of GPG. Therefore it should work correctly in every respect in
Windows (including correctly sized buttons).

This requires native Windows code to resize a button in a dialog. This is to
much work for something which is basically a debug tool. I have called several
years for help on building a good native Windows tool (without MFC and such) to
no avail.

Feel free to send a working patch to gnupg-devel@

Even so, this is a bug. As such, it should be fixed.

It can be specified by scdaemon's option. Now in 2.0.x and 2.1.x, it does
partial match for PC/SC.
So, this issue is now closed.

Note: for more information about this issue, please refer to:

  T1945

  https://wiki.gnupg.org/GnomeKeyring

(I've added this here, since this page is one of the top hits on ddg and google
when searching for the warning message.)

Thanks for the information.
I think the complete IDNA and co are an big mining field until to day.

Sure it used and thus read! You only need to look at the code for 5 seconds!
And no, it is not a lock. Read the comment at the var definition.

Yes it is not for a reason - checkout the comments to see why.

No c+p of warnings please! Use gnupg-devel instead.

It is just warning which does not matter if you are using a released tarball.
The next release will support newer autotools and has updated helper files.

Ok, thanks for the feedback.

I noticed your address elsewhere and wondered whether my script can handle it.
They do. However, gpg has not a complete parser but tries to make sure that the
user id looks like a valid address.

Use --allow-freeform-uid and enter what ever you like.

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.

GOT_IT merely tells that a line was received. There is and can't be any more
semantics.

I am not yet sure whether to keep GPG_AGENT_INFO.

I have not asked a single question in this thread; this is a bug report, not a
question. You have not explained adequately why this is not a bug.

Please discuss coding questions at gnupg-deel and not in the BTS.

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

I could not easily figure out what I was supposed to infer from the source code
of gpa or gpgme, but after playing about with it, I suppose I can detect the
error by noticing that the next GET_LINE issues a keyedit.prompt rather than
continuing with the workflow. This means I will have to write some state-keeping
logic instead of merely switching on the GET_LINE, and all users of this
interface will need to implement a similar thing.

To reduce the complexity for scripters here, might I suggest adding an extra
parameter to GOT_IT to explicitly communicate to the client script about any
errors? At least from the gpa/gpgme code it seems there is a generic parser that
can cope with extra parameters to any status line.

If anyone is affected by this (I don't know of others using this interface),
they can easily rewrite their parsing code to cope with both the old and new
GOT_IT lines (with or without a parameter).

BTW, this is the sort of thing that documentation would be helpful for.

The starting value is Certify+Sign for some options and Certify+Sign+Encrypt for
other options. This should be output in the status file descriptor so that a
script knows what it is doing.

Alternatively, the defaults should be committed to in public API documentation
that is guaranteed to not change, rather than source code. As you said yourself
in ML, one should not rely on the CLI to remain static.

I suggest that an option be added for the user to "set same as master key". This
will be the majority use-case.

But this might be done by accident, such as in old shell environments. Do you
consider GPG_AGENT_INFO with a different homedir, to be a valid use case? If
not, you should get rid of it, because otherwise it might be confusing and trip
users up.

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.

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.