Proposal: Add a function to handle modification of a key's trust level about python-gnupg HOT 3 OPEN

One initial thought was to simply document adding --trusted-key to the options. Unfortunately though that flag isn't whitelisted.

Another theorized workaround was to use something like:

gpghome = tempfile.mkdtemp(prefix='coreos')
config = open(os.path.join(gpghome,"gpg.conf"),"a+")
config.write("trusted-key 0x50E0885593D2DCB4\n")       
config.close() 
gpg = gnupg.GPG(homedir=gpghome)
gpg.import_keys(COREOS_PUB_KEY)

Alas, while this writes the file correctly, it's not processed because of the use of --no-options in the default flags passed to gpg.

from python-gnupg.

Any thoughts on this, Isis?

from python-gnupg.

@brianredbeard @fivetonsflax Going with the --edit-keys feature would be the "best" way to go, however doing so would likely be rather complicated, we'd have to probably use something like expect to script what we expect the output to be. However, the output in the interactive --edit-keys menu is extremely variable between GnuPG versions, and we'd need to provide other careful manipulations such as to ensure that the output we're running an expect statement on is in English, etc.

The easier way to go would be the --trusted-key feature, although that would cause any signatures (even certification signatures made on other keys) which have been created by the "trusted-key" to be calculated to be trustable at the same level as if the user had made those signatures themself with one of their own secret keys.

@brianredbeard Yes, we use --no-options so that the parsers aren't bypassed via options placed into a config file. That is, we purposefully don't support config files. (Doing so would also add compatibility/debugging issues, as the commands which were actually issued to the GnuPG binary wouldn't be the ones which python-gnupg meant to issue, and we'd likely get users complaining that python-gnupg had broken something without realising they had some incompatible settings in their config file.)

@brianredbeard One workaround which could be used is to add --trusted-key KEYID to the gnugp.GPG.options list. Any flags which are allowed and are within gnupg.GPG.options will get appended to all commands run thereafter. However, python-gnupg's commandline/flag parser acts as a whitelist (in order to avoid the shell injection which "upstream" a.k.a. Vinay Sajip's version of python-gnupg is vulnerable to), and --trusted-key isn't currently within any of the whitelisted flag groups… so… just adding --trusted-key KEYID to gnupg.GPG.options currently won't work, as that whitelist will reject it. If --trusted-key were added to the flags whitelist (specifically, it should go in the hex_options frozenset in the gnupg._parsers._get_options_group() function), then this would work, and the validity of any KEYID listed afterwards would be automatically checked by gnupg._parsers._is_hex() function.

from python-gnupg.