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.

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.

Consider this a feature.

There are no starting values. Please use the source code.

Please read the docs and sample code (I suggest gpa and gpgme). GOT_IT
indicates that a line has been received in response to a GET_xxx status.

It does not unless you override it with GPG_AGETN_INFO.

That is just fine. I don't want to throw out my money for nothing.

Nope. We discussed this already at the ML.

Using a question mark on prompts is a common behaviour for at least 35 years.
Thus one can expect that.

That is exactly the idea. Walk it through manually and you see what you need to
type. Adding docs bearks the risk that the docs is not in sync with the code
and thus we would need to run tests to make sure this is the case. The order of
the prompts depends on so many factors that a complete documentation si not
possible.

This is a duplicate of T1718

Duplicate of T1718

Got two more reports about this for Windows XP users. So we can safely assume
that this was not just a corner case problem for a broken setup of the Original
Reporter but that it is a real problem.

I'll add a reversion of the commit mentioned fpr 2.2.3

The same applies for the key export prompt, too. Currently it says something
generic about "the key has no passphrase, please provide one to export".

(My suggested examples also have some visual similarity between actually similar
options.)

(to verify the signature, remove the line-break between "causes a" and "warning")

Hello, Werner, Kindly have a look at this bug and patch,as and when you are
free. Thanks.

Sorry, cross-compiling from Windows to Windows is not supported. You need a
POSIX platform and mingw to build for Windows.
Changing this is probably possible but I do not have the time to care about this.

As a starting point, look at src/mkheader.c .

I will add a category for libgpg-error

D250: 508_07-gen_w32.patch

I guess that problem because gpgrt_lock_t is generates using gen-posix, but
used win32 lock objects (critical sections). I tried to patch generation
using gen-w32 and looks like that generator is unfinished just now. i made
ugly "fix" which will generate gpgrt_lock_t like in posix. patch in attach.
But i worried that alignment should be rechecked and initialization with
GPGRT_LOCK_INITIALIZER

Had a go at this myself. I've attached a patch that checks the gpg-agent version
before migration.

Output when an old version is found:

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: starting migration from earlier GnuPG versions
gpg: error: GnuPG agent version "2.0.22" is too old.
gpg: Please start an updated GnuPG agent.
gpg: migration aborted

Output when gnome-keyring running around:

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: starting migration from earlier GnuPG versions
gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not
interfere with the GnuPG system!
gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.
gpg: migration aborted
gpg: no default secret key: No secret key
gpg: signing failed: No secret key

The error message should also occur in case gpg-agent can not be started at all.
It happens when "GETINFO version" errors. So its generic.

D252: 507_0001-Check-gpg-agent-version-before-2.1-migration.patch

D251: 506_configure.ac.patch

There are 2.1 beta versions which support this.

What I implemented now is a simple one item cache for the last used passphrase.
This works in all standard cases. Trying more keys is not possible because
unprotecting a key introduces a delay to help against dictionary attacks.

Meanwhile done.