[Mailman-Developers] Fwd: Re: GSoC Updates

Fri Aug 16 11:42:07 CEST 2013

-------- Original Message --------
Subject: Re: [Mailman-Developers] GSoC Updates
Date: Thu, 15 Aug 2013 19:44:43 +0530
From: Abhilash Raj <raj.abhilash1 at gmail.com>
To: Stephen J. Turnbull <stephen at xemacs.org>

Thanks for the replies, I tried working on it and it was good enough to
be used for now. Thanks Steve for trying it yourself.

I have another few set of question now as I move towards signing and a
few answers to it also(which may be wrong please correct me).

1) How do list owner create keys? What parameters? Which address?

I think I will write a small doc on how to create key via command line
in linux using gnupg and copy paste the ascii armoured text to
postorious ui(which will be created soon). About the address I think
owner can create a key using posting address with a min key length of
1024? or else mailman rejects the key? MD5 hash should be discouraged
and at least SHA1 should be used?(although I found this[1] that even
sha1 should not be used)

2) RSA or DSA keys?

DSA can only be used for signing but is faster than RSA, although for
now our scope is limited to signing later on we "will" add encryption so
I think we should stick to RSA?

3) How to manage paraphrase(or passwords) for keys?

In previous discussions we decided to use gnupg-agent and I although I
haven't tried it. Any other suggestions to it?

Also one more thing while running tests i noticed many other tests are
breaking as initially a simple message could pass though
"default-posting-chain" but now we need a multipart/signed message. So
should I worry about changing all other tests?

---
Abhilash Raj

[1]: http://lwn.net/Articles/337745/

On Wednesday 14 August 2013 02:05 PM, 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)
>>>> str(crypted)
> '-----BEGIN PGP MESSAGE-----
> Version: GnuPG v1.4.14
> (Darwin)
> 
> hQIOAxjgOuNvO22tEAgAgPUFFCFDKe8zSWt42IG7LkLWWbbTCiAsO7aM2pEgtFrI
> KxRklwvEOX7bj5cYbmGr1PeM2IH58T4gMMHsYuOUyNzxS1mbsXZ9C4rpE0QJSkPY
> +5Z10dpHEyAZ030g6uBeubFHC+78as1s10UP16zlVgs2AeZwfM88OBocs7FmUdZr
> X5uAUxpB5RGET/zc2uHvBzIigXTzUrS8LrTtPfhyP8jCia6klX/2+2Q3gPlENoaP
> PkIx/vZ7aKCIKyoP+pbLlwGAb/CX1WoQgyrsNFApg/HJhZ3ZLYKcvIqO3PNejOcN
> 8ZYLRV4Uz0tLCuALCccw+XEZSQTKBoemXqVUwSKCAAf+OiHpMqDMoO7ReVVZg841
> MnRcZzfUnL8mj1FZwnr3iTcQ7BdUbu5vMAjn0SIlBISquu0rZi+wynGwgSpWnJeF
> Llh+gjizNuHUxtO96phbwMeyVrD1yKSxkxC9cY0r8NBo/MTwUmyMCHNKpj0qrome
> GZI2ekhYjLWfAbX3c6dwBx7pQhwkHkgMmoY6yN0OpLf1urnHGpv+AsEwDmWZ8mz3
> CLtD/l9eMl4LGIHNSV7yQ4lAzhYMenNdxkYJyKtxEvM1BFdqOblRb/h+B3X/xtT/
> 6ATAK1mZz1nU4H2EB1EvS4rbbQJ6oIevQSz3r/G6jSI7PqPDJvhnzQBrN7wh1pep
> ldJQASeq3bCushTnFolWVxOgswXm2VFMPnhqEVxBJrZ12nZO2LGN7Y2/W+qQ/Qqb
> DdYqbYOXNFW9r9p7ugJKKD1kK3XUkTC0Y+t1I/a7dLJBvpA=
> =olXg
> -----END PGP MESSAGE-----
> '
>>>> of = open ('/tmp/cryptfile', 'w')
>>>> of.write(str(crypted))
>>>> of.close()
>>>> signed = gpg.sign('A bit of random text.', passphrase=u'Not useful without my keyring.', keyid=u'gpg-tester at turnbull.sk.tsukuba.ac.jp')
>>>> str(signed)
> '-----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> A bit of random text.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14
> (Darwin)
> 
> iQEcBAEBAgAGBQJSCz30AAoJEBeoEMM73++oWGcH/jS3AJ6OZLm8JHiLAI0AzCXe
> muRVhPPfGrqL/Jr+l9WA8Zj3pClHa04H0ha3nvYFHPhN30lFDDw56iCPMA+DbJbr
> 2BeqUSfJj36EGHOi8yV5iljZA4NhAw9qqhwQz7kas+KTeY8+98DQDS10ixVZ92Gv
> NDxQCKcyTj+6leqy3ePRAgXP5DouTGXntupzPQzcbQW6L8X6h6STOiLAAGKXpGJm
> t4Fruvbb3kAcqDGCp5Y9kLrxd1unlCp9leoeJeG5NZ5IcI2B4qUwqKdydu9ZMJxS
> kJYJR1ZNVMtQh/kMNA87GMNv4nd8d5QPD+bm5b4L5BDlibzMGb5Q80mJAKD5xqo=
> =qHjE
> -----END
> PGP SIGNATURE-----
> '
>>>>
> 
> Decryption of the encrypted file works.  I didn't verify the
> signature, but it looks like it's working.
> 
>  > Also I understand that keeping key safe is one of the important
>  > tasks but for the time-being I am simply adding the public and
>  > secret keyrings in "VAR_DIR/gpg/", all the list's private keys are
>  > in `secring.gpg` and all the list's public keys are in
>  > `pubring.gpg` and all the user's public keys are in
>  > `userring.gpg`. It will be changed to keep the secret keys at a
>  > more safer location.
> 
> I agree with Richard that there's no particular reason to do anything
> but put the public keys on one ring.
> 
> I don't see any point in putting the private keys somewhere else.  As I
> wrote elsewhere, the weak point in the private keys is the need to
> supply a password, not the location of the file containing the key.  I
> wonder if there may not be a way to do this using agent forwarding so
> that the private keys are kept on a different host.
> 
> The only issue I can see is that *if* at some point it becomes
> feasible to use agent forwarding, I suspect only one agent can be used
> per GPG subprocess.
> 
> 
> Footnotes: 
> [1]  Has anybody else noticed that both gpg's UI and its documentation
> seem designed to make it as hard to use as possible?
> 