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.

Done with commit ae3d1bb. It works by checking whether the latest encryption
subkeys expires in less then 10 days. Should be backported to 2.0.

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.

accidentally removed the original reporter from the nosy. Sorry (readded)

I can reproduce this on my test system, if I just create a folder with the name
"földer" Kleopatra / gpg2 /gpgtar don't show an error they just fail silently
and create an empty archive. I guess there is some utf8 to system locale
conversion missing.

As kleopatra offers me the option to "Delete unencrypted files" after encryption
I am marking this as critical as it can lead to data loss.

At least there should be an error so that the removal after the encryption is
not done!

T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.