--gen-key & pipes

Werner Koch wk at gnupg.org
Mon Nov 8 15:37:20 CET 1999


Anthony Mulcahy <anthony at kcn.ne.jp> writes:

[Please check that the length of a line does not exceed ~72
characters]

> I examined the source of ttyio.c and it seems that gnupg doesn't use standard input to read in the user input. Is this correct? What is the reason for this I/O method? Does it have some advantages over the standard I/O routines? For other commands, I can easily read the output of the gnupg child process using pipes, but the --gen-key command seems to be different.

Consider this example:

$ foo | gpg --sign | mail otto at mueller.de

Here gpg needs to get the passphrase to unprotect the secret key. 
However, stdin is already used for the data to be signed.  Therefore
the only solution is to use /dev/tty to read the passphrase.  

The correct way to do this is by using the Shared Memory approach of
GnuPG or to use expect(1).  If you are willing to wait a while, PGG
(Privacy Guard Glue) will give you a library to handle such issues
very comfortable - in fact it is targeted as a layer between a
frontend and gpg.

libgcrypt will provide a way to generate key material but it will not
know anything about OpenPGP - it is really a low-level thing.

Here is a small picture:

  xxxxxxxxxxxxxxxxxxxxx   xxxxxxxxxxxxxxxxxxxxx
  x   Frontends etc.  x   x   CORBA Service   x
  xxxxxxxxxxxxxxxxxxxxx   xxxxxxxxxxxxxxxxxxxx
           |                        |
     C API +------------------------+
           | 
  xxxxxxxxxxxxxxxxxxxxx
  x       PGG         x
  xxxxxxxxxxxxxxxxxxxxx
           |
      some special
      protocol /
    process barrier
           |
  xxxxxxxxxxxxxxxxxxxxx  xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  x      GnuPG        x  x    Other Apps            x
  xxxxxxxxxxxxxxxxxxxxx  xxxxxxxxxxxxxxxxxxxxxxxxxxxx
           |                          |                   
           +------------+-------------+---------------....
                  C API |
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  x                libgcrypt                        x
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


Michael may be able to tell you more about the status of PGG.  
In the case your Frontend is not GPLed you have to communicate
directly to GnuPG (see tools/shmtest.c).  The far easiest way to 
do this might be expect(1).


-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013



More information about the Gnupg-devel mailing list