If you order such a docuemntation I'll be glad to add it. Contact me at my
company address.

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

You responded to my previous suggestions, and this is my next iteration, with me
trying to take into account your comments.

I find that making related options visually related, helps the user to better
intuitively understand what they do. The current options don't do this.

You also had a comment along the lines of "sign is not accurate because there's
also certify and authenticate", but a few current options also have this flaw. I
think it's OK, but it's better to do this consistently.

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.

If "a complete documentation is not possible", then it is not fit for purpose as
an API to be scripted, and you should stop advertising that functionality in public.

If you do not have time to do this documentation, the correct response is to say
"I do not have time to do this", but leave the bug open, because it is something
to be resolved in the future.

An exposed public interface that you expressly suggested me to use in a script,
is *supposed* to have documentation associated with it. That is basic standard
software engineering. You don't see standard library authors respond with "just
try out the function to see what happens", when someone points out missing
documentation.

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.

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.

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

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.)

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

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.