Hi everyone,
This will be my second update email to mm-dev after gsoc started, i'll be
sending weekly summaries in the future. The ci-tool(please suggest some
nice name) is almost finished, i need few more days to get it working on
multiple projects under mailman suite. The following parts of ci-t
Daniel Kahn Gillmor writes:
> On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote:
> > The last time I looked (~10 days ago), that was the implementation:
> > look only at the message-level Content-Type, ensure it's
> > multipart/signed, check that there are exactly two parts and that the
> > se
On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote:
> The last time I looked (~10 days ago), that was the implementation:
> look only at the message-level Content-Type, ensure it's
> multipart/signed, check that there are exactly two parts and that the
> second is "application/pgp-signature".
hum,
Daniel Kahn Gillmor writes:
> On 08/28/2013 09:37 PM, Abhilash Raj wrote:
>
> > 1) There is a 'signature rule'[1] that can verify signature from the
> > users whose public key is stored in 'var/gpg' directory insider
> > 'pubring.gpg'. This rule also verifies that the email has only two parts
Hi Abhilash--
I haven't looked at the code much yet, but this is a pretty exciting
report! I'm glad to hear everything you've done.
On 08/28/2013 09:37 PM, Abhilash Raj wrote:
> 1) There is a 'signature rule'[1] that can verify signature from the
> users whose public key is stored in 'var/gpg'
Hi all,
So I think my work inside mailman for signing and verification is almost
complete, here are a few things that I have now working and it would be
very nice if some of you can have a look at the code and let me know if
the implementation is correct(the logical and the pythonic way).
1) Ther
Daniel Kahn Gillmor writes:
> On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote:
> > Python 2.7.5 (default, Aug 1 2013, 23:58:20)
> from gnupg import GPG
> gpg =
> GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec')
> crypted = gpg.encrypt
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
Abhilash Raj writes:
> Then i guess I will simply create a new key with list's credentials
> when the list is created,
I really think that's best for nontechnical users. Read the article
Terri cited on mailman-developers a few days ago.
Adding an upload option (non-trivial to implement secure
Abhilash Raj writes:
> > I think the address should be $LIST-owner@fqdn. For other parameters,
> > defaults are OK I think (size=2048, type=RSA IIRC).
>
> Here should not the address be the list's posting address? Like for
> mm-dev list should it not be "mailman-developers@python.org"?
May
On Friday 16 August 2013 10:35 AM, Stephen J. Turnbull wrote:
> Abhilash Raj writes:
>
> > 1) How do list owner create keys? What parameters? Which address?
>
> python-gnupg provides a key-generation API, GPG.gen_key().
> Alternatively, this could be done manually by the trusted
> site-manager.
On Friday 16 August 2013 12:30 PM, Stephen J. Turnbull wrote:
> Abhilash Raj writes:
>
> > But can we achieve required randomization to create keys on virtualized
> > systems?
>
> Not your problem. We can do it on physical hosts, and that's good
> enough. People who care this much about secur
Abhilash Raj writes:
> But can we achieve required randomization to create keys on virtualized
> systems?
Not your problem. We can do it on physical hosts, and that's good
enough. People who care this much about security will be prepared to
pay for it. Generalizing to handle sites that need
Barry Warsaw writes:
> On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote:
>
> >[1] Has anybody else noticed that both gpg's UI and its documentation
> >seem designed to make it as hard to use as possible?
>
> Sadly, I think this is one of the biggest reasons why we've never
> seen w
On 13-08-14 2:35 AM, Stephen J. Turnbull wrote:
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?
Not only have people noticed, but " Why Johnny Can't Encrypt: A
Usability Evaluation of PGP 5.0" is often require
I agree with everything written elsewhere by Steve and Richard.
On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote:
>[1] Has anybody else noticed that both gpg's UI and its documentation
>seem designed to make it as hard to use as possible?
Sadly, I think this is one of the biggest reasons
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 document
Abhilash,
I see no reason to have more that one keyring for public keys and another for
the private ones.
In both cases, those key rings are a flat table indexed by the Key_id. It
doesn't matter if the "owner" of the key is a list or a subscriber (or any
other user) As for user keys, I think th
Hi all,
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) so we need key_id. As barry suggested we can create a
mapping of ad
19 matches
Mail list logo
