[Mailman-Developers] GSOC Midterm Report

Abhilash Raj raj.abhilash1 at gmail.com
Fri Aug 2 14:19:30 CEST 2013


On Thursday 01 August 2013 03:47 AM, Daniel Kahn Gillmor wrote:
> I'm excited to see this work, Abhilash!
> 
> Do you have a demonstration instance of this code up and running anywhere?

No, not yet. Even though signature verification and signing work
separately still some work needs to be done to make both work together.

> On 07/31/2013 02:43 AM, Abhilash Raj wrote:
>> * Signature verification using `python-gnupg` was a PITA to me for
>> sometime. The way it accepts the string and signature for detached
>> signature is not documented at all and is converse of what I could think
>> of. It just occurred to me to try out the other possibility which turned
>> out to be the right way.
> 
> have you reported this as a bug to the python-gnupg folks?  I imagine a
> patch to improve their documentation would be welcomed.

It seems that there is no public repository for this project. I will
still open a issue.

>> * Deciding the structure of the signed message that we were going to
>> send out. Initially it was decided to leave sender's signature intact so
>> that if someone wants to verify it he can do it, but there can-not be
>> two 'pgp-signature' parts in a conventional multipart/signed message. I
>> wrote the code to follow an internet-draft[2] i discovered one-day. But
>> then I commented out the code and also added another format
>>
>> mutipart/alternative {
>> 	multipart/signed { text/plain, application/pgp-signature }
>> 	multipart/signed { text/plain, application/pgp-signature }
>> }
>>
>> Some furthur assistance and research on which format do MUAs support the
>> most should be implemented.
> 
> While you can't have two pgp-signature parts in a conventional
> multipart/signed message, you *can* have two OpenPGP signatures within a
> single pgp-signature part.
> 
> So it sounds like you have three options:
> 
>  0) two OpenPGP signatures within a single pgp-signature part
> 
>  1) your duplicated multipart/alternative approach
> 
>  2) the recommendation in the internet draft you found.
> 
> Of those three, i recommend going with 0 first, then 2, then 1.  Having
> a message with dual signatures is going to be surprising to many MUAs
> that haven't thought through the implications, no matter what formatting
> you choose.  keeping the message structure simple and standard
> (suggestion 0) seems like it will be the least surprising.
> 
> Have you generated example messages of these forms and tried them with
> various OpenPGP-capable MUAs?

I haven't but I am working on that. Can you point me to some
implementation using 0)?

>> Future Plan:
>> The next plans for this project include testing all the above parts
>> thoroughly and then moving on to creating a PKI for the key.
> 
> Can you explain more what you mean by "a PKI for the key"?  I'm curious.

Now as the signing part is almost done except for to-be-able-to-select
the key for signing(now python-gnupg signs using the first found key in
the secret keyring) we need the proper infrastructure for the key
management. Where will the public keys of the users be stored? Where
will the secret keys of the lists be stored? How will they be accessed
by mailman?

For now simply a directory is created under var-directory where
pubring.gpg and secring.gpg exist. I am myself on to finding solution to
all these question, although I think I will be needing some serious help
on this as I have very less idea how to actually implement it.

> Nice work on all this!  I look forward to seeing it in action!

Thanks

> Regards,
> 
> 	--dkg
> 

---
Abhilash Raj


More information about the Mailman-Developers mailing list