Skip to content

Latest commit

 

History

History
114 lines (90 loc) · 5.11 KB

TODO

File metadata and controls

114 lines (90 loc) · 5.11 KB

-*- mode: org -*-

I/O

in GPG.__make_args()

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.

look into RDBMS/ORM for public key storage

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.

Key editing

add ‘–edit-key’ feature

see :compatibility:gen__key_input:

Compatibility between GnuPG versions

GnuPG>=2.1.0 won’t allow key generation with preset passphrase

add version detection for GPG.gen_key_input()

DONE: use gnupg._util._is_gpg2() and gnupg.util._is_gpg1() to check versions

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.

passphase setting for GnuPGv2.x in GPG.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’.

add ‘–edit-key’ feature

This would be necessary for adding a passphrase to the key after passwordless generation in GnuPG>=2.1.0.

GnuPG==1.4.12 doesn’t process “Key-Type: default” in batch files

DONE: GnuPG version detection in gen_key_input() was added in commits 6eccbe704841cca90573dc554019712528d927a0 and 1e867d6e117f603cd9f2238641a1fb9cb87d4b51

(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 ∴

Code cleanup

in parsers.__sanitise()

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.

in parsers.__is_allowed()

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.