In the man page of gpg(1) it says:

--export-options parameters

export-minimal
    Export  the  smallest key possible. This removes all signatures except the

most recent self-signature on each user ID. [..]

If you actually do this to my key however, you will see that the resulting
output contains Nicolas' signature on my key, which is against what
"export-minimal" is supposed to do.

Thanks, fixed in 2.1.2. (I had to run --edit-key and --check-trustdb first.)

For comparison, running the below commands using gpg 1.4.18, does *not* exhibit
the bug - after importing dkg's key, my own key's validity remains as "ultimate".

What "that" are you referring to? In all the versions of GPG I've tried, 1.4,
2.0, 2.1 including this current one in git, it is possible to create a
Certify-only master key by toggling off "Sign" (and "Encrypt", for RSA).

I am saying this should be possible for the "=flags" syntax as well. I would be
happy with either "=" or "=c". The latter is clearer, but inconsistent with the
existing syntax in git which ignores "c" completely, and just forces Certify on
for the master key and off for the subkey.

$ gpg2 --full-gen-key --expert
[..]
Please select what kind of key you want:
[..]
Your selection? 8

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
[..]
Your selection? s

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt
[..]
Your selection? e

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify
[..]
Your selection? q

[..]
GnuPG needs to construct a user ID to identify your key.

Real name: Testing
Email address: lol@test
Comment:
[..]

gpg: key 0822FCC2D521C45C marked as ultimately trusted
public and secret key created and signed.
[..]

$ gpg2 --edit-key lol@test
[..]

Secret key is available.

pub rsa1024/0822FCC2D521C45C

created: 2014-10-02  expires: never       usage: C   
trust: ultimate      validity: ultimate

[ultimate] (1). Testing <lol@test>

gpg>

Hi, this does not currently allow me to set the master key to Certify only. If I
enter "=" or "=c" it just ignores me and goes back to the default value. Looking
at commit 7ff4ea21 I'm not sure why this is the case, since current should be 0
at the end. Setting "=a" gives me a CA-use master key as expected.

It would be good to note in the help text that a master key always has the C
flag, and a subkey does not (as far as the "=" syntax is currently implemented).

Thank you! This solution sounds good, I will test it this weekend.

FYI, just adding a "Type ? for help." after "Invalid selection." would improve
the situation massively.

Really, which prompts are those?

$ sh
$ ?
sh: 1: ?: not found
$
127

$ ed
?
?
1

$ bash
$ ?
bash: ?: command not found
127

$ zsh
% ?
zsh: no matches found: ?
%
1

$ man man
?
Pattern not found (press RETURN)

$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
?
(standard_in) 1: illegal character: ?

$ gdb
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) ?
Undefined command: "". Try "help".
(gdb) quit

Fuck, even vi tells me "type :help<Enter> or <F1> for on-line help"

$ python
Python 2.7.8 (default, Sep 9 2014, 22:08:43)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

?

File "<stdin>", line 1
  ?
  ^

SyntaxError: invalid syntax

$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ: ?

<interactive>:2:1: parse error on input `?'
λ:
Leaving GHCi.

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.

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.

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