-*- mode: org -*-
It would be nice to have an option for gen_key() gnupg.py:927 to automatically switch before key generation to a new tempfile.mkdtemp() directory, with a new keyring and secring, and then to rename either the directory or the keyrings with the long keyid of the key which was freshly generated.
It would be nice to make the file descriptors for communication with the GnuPG process configurable, and not the default, hard-coded 0=stdin 1=stdout 2=stderr.
see http://stackoverflow.com/q/1235594 and http://elixir.ematia.de/trac/wiki
memcached and pymemcached were the first ones I looked at, then I discovered redis, which seemed better. At some point we should look into using elixer, mentioned in the above SO post, so that the backend DB can be chosen freely and we´re not restricting users to only memcached/cassandra/redis/sqlite/etc.
see :compatibility:gen__key_input:
In the docstring of GPG.gen__key_input() gnupg.py:1068, for the parameter ‘passphrase’, it is explained that:
:param str passphrase: The passphrase for the new key. The default is to not use any passphrase. Note that GnuPG>=2.1.x will not allow you to specify a passphrase for batch key generation – GnuPG will ignore the “passphrase“ parameter, stop, and ask the user for the new passphrase. However, we can put the command ‘%no-protection’ into the batch key generation file to allow a passwordless key to be created, which can then have its passphrase set later with ‘–edit-key’.
If we add a GnuPG version detection feature (the version string is already obtained in GPG.___init___() gnupg.py:407), then we can automatically chain GPG.gen__key_input() to another new feature for ‘–edit-key’. This chaining would likely need to happen here gnupg.py:1146.
This would be necessary for adding a passphrase to the key after passwordless generation in GnuPG>=2.1.0.
(python-gnupg)∃!isisⒶwintermute:~/code/riseup/python-gnupg ∴ ipython WARNING: Attempting to work in a virtualenv. If you encounter problems, please install IPython inside the virtualenv.
In [1]: import gnupg GnuPG logging disabled…
In [2]: gpg = gnupg.GPG(homedir=’./tests/doctests’)
In [3]: key_input = gpg.gen_key_input()
In [4]: print key_input Key-Type: default Key-Length: 4096 Subkey-Type: default Name-Email: isis@wintermute Expire-Date: 2014-05-28 Name-Real: Autogenerated Key %commit
In [5]: key = gpg.gen_key(key_input)
In [6]: print key.stderr gpg: -:1: invalid algorithm [GNUPG:] KEY_NOT_CREATED
In [7]: quit() (python-gnupg)∃!isisⒶwintermute:~/code/riseup/python-gnupg ∴ which gpg /usr/bin/gpg (python-gnupg)∃!isisⒶwintermute:~/code/riseup/python-gnupg ∴ gpg –version gpg (GnuPG) 1.4.12 Copyright (C) 2012 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.
Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 (python-gnupg)∃!isisⒶwintermute:~/code/riseup/python-gnupg ∴
Ughh…this is the ugliest code I think I’ve ever written. It works, but I worry that it is fragile, not to mention I have trouble reading it, and I fucking wrote the damn thing. There’s probably not much that could be done to make it more Pythonic, because type checks and input validation are pretty much intrinsically non-Pythonic. But did i mention that it’s ugly? I’m sure these functions would be pretty glad to get a shower, shave, and haircut.
There is a lot of madness dealing with stupid things like hyphens vs. underscores, and lists of options vs. strings. This can definitely be cleaned up.