[Mailman-Developers] GSoC Updates

[Daniel Kahn Gillmor]

On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote:
> Abhilash Raj writes:
> 
>  > After midterm evaluations I have been working on signing the message
>  > using one the keys associated with the list, now since `python-gnupg`
>  > does not allow selecting keys with key credentials( like address or
>  > list-name name)
> 
> Have you tried this?  In the GPG documentation, "key ID" often
> actually means any of the above.[1]  If python-gnupg simply passes its
> argument to the gpg process, it should Just Work.  Anyway, it seems to
> work for me (some output edited for clarity):
> 
> venv27 abhilash 15:39$ python2.7
> Python 2.7.5 (default, Aug  1 2013, 23:58:20) 
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> No entry for terminal type "emacs";
> using dumb terminal settings.
>>>> from gnupg import GPG
>>>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec')
>>>> gpg.list_keys()
> [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'',
>   'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048',
>   'ownertrust': u'u', 'algo': u'1',
>   'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8',
>   'date': u'1376462161', 'trust': u'-', 'type': u'pub',
>   'uids': [u'GPG Test User <gpg-tester at turnbull.sk.tsukuba.ac.jp>']},
>  {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'',
>   'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024',
>   'ownertrust': u'-', 'algo': u'17',
>   'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373',
>   'date': u'1183228371', 'trust': u'-', 'type': u'pub',
>   'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) <stephen at xemacs.org>']}]
>>>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen at xemacs.org', always_trust=True)

hmm, always_trust=True is probably problematic -- if someone manages to
inject another key with the associated User ID earlier into gpg's
keyring, then their key will be used before the correct key.

I agree that gpg should be able to figure out the key to use given the
e-mail address, but i'm not sure if it necessarily will if there are two
keys which both claim a given User ID and only one has a valid binding
(i.e. a proper OpenPGP certification from a trusted introducer).

so the above test worked, given the keyring that you had, but it might
result in *not* working (e.g. by encrypting to the wrong key) given a
different keyring.

fortunately, in the current implementation we're only worrying about
signing, not encryption; so the relevant issue is the choice of secret
key, and we don't expect other users to be able to inject data into the
secret keyring, so this shouldn't be a concern.  right?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130821/a6ccec94/attachment.sig>