> I can't reproduce this - what version of gpg are you using, and on
> which OS?
I saw this using gpg.exe 1.4.11 on Windows 7 with Gpg4Win installed
(others like WinPT and PGPTray also on the system). It appeared that
gnupg.py found the gpg4win's gpg.exe, which started gpg2.exe which
started gpg-agent.exe which created S.gpg-agent, and then gpg-
agent.exe would keep running, and also dbus-daemon.exe started. I'm
still not clear on exactly how that happened. The goal was
simplicity, to sidestep any other products and just call gpg.exe
1.4.11, and 'gpgbinary' (shown below) resolved that.
Some python code below for tinkering if someone wants to try to
reproduce it (you'll need gpg.exe and iconv.dll in the current dir).
By adding the gpgbinary arg to specify the full path to gpg.exe
including the 'gpg.exe' itself, that kept other encryption products
from crashing the party (via registry keys or whatever). Previously I
had interpreted the documentation incorrectly and simply did not use
gpgbinary. The docs say:
gpgbinary (defaults to “gpg”)
The path to the gpg executable.
[...maybe add an example full path to that to help insure clarity].
#!python
import os
import gnupg #
http://packages.python.org/python-gnupg/
gpg_home = os.environ['APPDATA'] + "\\gnupg"
gpg_binary = os.getcwd() + "\\gpg.exe"
#gpg = gnupg.GPG(gnupghome = gpg_home, verbose = True)
gpg = gnupg.GPG(gnupghome = gpg_home, verbose = True, gpgbinary
= gpg_binary)
input_data = gpg.gen_key_input(
key_length = 2048,
subkey_length = 2048,
key_type = "RSA",
subkey_type = "RSA",
name_real = "sam juan",
name_email = "
som...@somewhere.com",
name_comment = "by gnupg.py",
passphrase = 'zzoo'
)
print "Creating keys"
key = gpg.gen_key(input_data)
print gpg.list_keys() # public keys
print gpg.list_keys(True) # secret keys