First of all, I suggest to use GPGME to access gpg. For an example on how to do
key signing you may want to look at GPA (start with src/gpgmeedit.c).

The gotcha for your problem is --commands-fd N. This will emit additional
status messages on which you have to react. I am sorry, that conrolling gpg is
somewhat complicated -this is due to the hseer amount of options the OpenPGP
protocol provides and of which gpg provides most of them.

For a simple script on how to sign keys, check out tools/signmany. This works
directly if there is only a single user id to sign and falls into gpg's own edit
mode if there are more keys. Sure, you would need a PTY to fully automate it.
But please do use --command-fd or GPGME's gpgme_op_edit API.

Thank you for the ideas.

So I've started poking around at GPGME, but I think it's a C-language
library and I'm using Python for my main program. So I suppose
one could write a Python interface to GPGME but that's really not my
issue, I already have a Python interface to GPG which is gnupg.py.

Also, I'm trying to write a cross-platform program, that will run on
any machine that has (1) gnupg, and (2) python. Adding dependencies
on infrequently used compiled C libraries will make that fail. The
theory here is that I'm writing a program that will actually encourage
people to sign each others' keys, by making it much simpler while still
secure, thereby making the web of trust much stronger.

I looked at GPA very briefly as well. It is also a C program. I
would consider adding the same multicast key-sharing functionality to
GPA, but that's a separate project. I don't think that doing that would
meet my goals of making it work on any platform that has gnupg and
that downloads my program. There is documentation that says GPA works on
Windows, but not on any other platforms (MacOS and Android seem
desirable for my program). GPA relies on GTK+ which again in theory
might be cross-platform but also doesn't seem *dependably*
cross-platform. And GTK+ itself seems to be going through some
huge upheaval that's obsoleting lots of stuff. I would prefer to
steer clear of all that useless complication and just write my
own little program using long established and widespread interfaces.

So thank you for these ideas, but they haven't solved my bug.

I will also investigate --commands-fd, but again, the only thing I am
going to want to do is to tell gnupg "yes, Yes, YES! Just do what I
asked you to do on the command line". I could add extra code that
swallows whatever gnupg gives me on --commands-fd and tells it "Yes",
and I will probably do that anyway since my code will have to work
with old, unfixed copies of gnupg. (Or it may be simpler to set up a
pty and just keep feeding it "yes\n" whenever it pauses, but that might
be more trouble to get working cross-platform.)

But, there is already a documented command-line option for "just do
what I asked you to do on the command line and stop asking me stupid
questions as if I was a human, which I am not", which is --yes. I
think that switch does not work. I don't understand why that is not a
bug.

John

The mostly used Python binding for GPGME seems to be pyme. However,
it does not yet support the edit interface thus for your task it is
probably not suitable either.

GPGME is actually available for all platforms and that is the reason
why I always suggest it. It even comes with a command line tool to
access gpg via gpgme. gpgme-tool is a debugging aid but useful on its
own for scripting purposes. It might make sense to add support for
some commonly used task to it.

I understand your concerns about GPA. The guardianproject has its own
tools based on GPGME but I have not yet looked at the key management.
Unfortunately I have no experience with MacOS and the folks providing
GnuPG for OS X seem to do their own thing. My main platforms are Unix
and well for the sake of most users Windows. Note that Python is not
a standard tool on Windows and due to different Python versions one
would need to distribute a separate copy. We don't have a useful
non-Microsoft packaging system for Windows which makes things hard.

The yes, yes, DWIM option has often been requested but it is not easy
given the complicated structure of OpenPGP and that some people want
to have full control over what and how they are signing. A
--sign-keys-as-most-users-would-do is of course be possible but it
needs to implement a policy into gpg which is not the best choice.
Putting this into a separate tools would be better.

Regarding --command-fd, the idea is that you can give it just a LF and
it would use the default. However, you need to detect certain prompts
and re-act on them. The most stable way to do this is of course a FSM
which can fail if a some GnuPG version changes things in way it does
not understand anymore. From a security point of view failing is
often better than continuing and possible introducing a security flaw.

The option --yes works only in certain cases, like "overwrite file".

If you send me a more detailed description of what you want to do with
your tool to wk@gnupg.org, we may be able to find a solution which
can also benefit GPA users (i.e. Windows).

FWIW, 2.1 will come with these new commands:

  --quick-gen-key user-id

    This is simple command to generate a standard key with one user
    id.  In contrast to --gen-key the key is generated directly
    without the need to answer a bunch of prompts.  Unless the option
    --yes is given, the key creation will be canceled if the given
    user id already exists in the key ring.

    If invoked directly on the console without any special options an
    answer to a ``Continue?'' style confirmation prompt is required.
    In case the user id already exists in the key ring a second prompt
    to force the creation of the key will show up.

  --quick-sign-key fpr [names]
  --quick-lsign-key fpr [names]

    Directly sign a key from the passphrase without any further user
    interaction.  The fpr must be the verified primary fingerprint of
    a key in the local keyring. If no names are given, all useful user
    ids are signed; with given [names] only useful user ids matching
    one of the- ses names are signed.  The command --quick-lsign-key
    marks the signatures as non-exportable.  If such a non-exportable
    signature already exists the --quick-sign-key turns it into a
    exportable signature.

    This command uses reasonable defaults and thus does not provide
    the full flexibility of the "sign" subcommand from --edit-key.
    Its intended use is to help unattended key signing by utilizing a
    list of verified fingerprints.

FWIW, 2.1.4 will also bring a

gpg --quick-adduid USER_ID NEW_USER_ID

I close this bug because the new features won't be backported to 1.4 or 2.0.