[Mailman-Developers] GSoc - Requirement from Mentor to complete the project

[Abhilash Raj]

Let me divide the project in a few pieces so that each can be
discussed upon separately.

* Firstly a utility to encrypt or decrypt the message. Well i found
[python-gnupg][1] for this purpose and would try to write a wrapper
around it for the use by mailman. But I found another option for it
[GnupgInterface][2]. GnupgInterface was used in the
[mailman-pgp-smime][3] patch for mailman and also has options to sign
and encrypt in one call of a function( unlike python-gnupg ). If
anyone has ever used any of these two would you please suggest which
one is better?

Also from this [document][4] I see that there are two ways to both
sign and encrypt the message:

    *  It is stated that the data is first signed as
multipart/signature body, and then encrypted to form the final
multipart/encrypted body.[5]
    * A method for signing and encrypting data in a single OpenPGP
message.  This method is allowed in order to reduce processing
overhead and increase compatibility with non-MIME implementations of
OpenPGP.

I don't have any links to prove, but I think we should use the first
one. Any thoughts about which one is easily and more widely used among
various MUAs?

* Now the second part as wacky mentioned - a framework for storing the
keys and handling the association of the key with a particular user.
This same framework would be used to associate other methods of
identification and authentication with the users.

* The point of encryption and decryption in the various queues. I was
of the opinion that the message is decrypted as soon as it enters the
IN queue and while its about to leave the queue it is encrypted with a
symmetric key algorithm using the list's secret key. And then it is
subsequently decrypted in the next queue and finally in the OUTGOING
queue it is signed and encrypted with each user's pub-key.
Any suggestions about this?


[1]: http://pythonhosted.org/python-gnupg/
[2]: http://search.cpan.org/~alexmv/GnuPG-Interface-0.46/lib/GnuPG/Interface.pm
[3]: http://non-gnu.uvt.nl/mailman-pgp-smime/
[4]: https://tools.ietf.org/html/rfc3156#section-6
[5]: https://tools.ietf.org/html/rfc1847

On Sun, May 5, 2013 at 10:00 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Abhilash Raj writes:
>
>  > 1) I need to discuss about the design of the idea that I want to
>  >    implement.  I know the rough bits but need help and comments on
>  >    what I proposed. This would require views from the whole
>  >    mailman-community.
>
> This is place for that, not private consultation with the mentor.
> Just start spelling out your ideas, and post them here for comment as
> they're developed to the point you can get useful comment.  And don't
> worry about whether you are doing it right: just do it.  Sooner is better.
>
> One reason for this approach is that as Google sees GSoC, one purpose
> is encouraging the student to develop his or her relationship with the
> community.[1]  The best case is somebody who enters with several months
> of  presence on the developer lists (but that is in no way required,
> it's more an "it would be nice if" example).
>
> We actually would like have the proposals posted here, but
> unfortunately that tends to interfere with evaluation for several
> reasons.  (One important one is that often several students propose
> similar projects, and if the proposals are public there's a very
> natural tendency for them to converge, making selection nearly
> impossible.)  Now that we have the proposals in full, we'd like you to
> start engaging the community by posting your ideas, designs, and
> questions here.
>
> It's probably best *not* to post big chunks of your proposal.  Maybe
> the "short description" as an introduction, but after that you should
> pick a particular task and get the community to help you start on it.
>
>  > 2) Apart from the corner cases mentioned in the proposal there might be
>  > many other not caught in my eye. I would need them to be pointed out so
>  > that a solution of it can discussed and then implemented.
>  >
>  > 3) There is a lot of cryptography in this project, so I would need a more
>  > experienced view to find and remove the security loopholes.
>
> These are more specific to your topic, but they are also best done on
> this list, especially the issues related to security.  The advantage
> of the mentor system is that you have somebody who has to look at your
> stuff.  Still, the best way is to get comments from a broad selection
> of developers and users.
>
>  > 4) Lastly since I am still a noob in programming I would need regular
>  > review on the code for the first 2-3 weeks so that I cam improve
>  > and write bug free production code.
>
> Well, the first thing to learn is that nobody writes bug-free code.
> Anticipate that your code is going to be buggy, catch as many as you
> can systematically (I recommend Watts Humphrey's book "Introduction to
> the Personal Software Process", I'm sure other mentors have their
> favorites).  Then get reviews from others (including but not limited
> to your mentor(s)).
>
> Once again, what we are looking for (Richard posted as representative
> of the mentor team) is discussion of your plans: the pieces of the
> design puzzle, of course, but also your motivation for proposing the
> project, and your plans for advancing it.
>
> I emphasize what Richard has already mentioned: this is not a test
> where you have to do everything yourself to get points.
>
> You will be evaluated on the functionality you present to us at the
> midterm and final evaluations, not on whether you wrote all the code
> yourself.  Some of the code you can borrow from existing modules, and
> some you can beg from others.  Your mentors are going to be working on
> their own projects, and schedules can be adjusted to provide pieces of
> the puzzle you need sooner rather than later.  Other experienced
> developers may be willing to help out.  In some cases you can get
> parts of what you need from other students in GSoC (but this requires
> delicate negotiation and careful management by the mentors involved;
> we'll cross that bridge if we come to it).
>
> The rest of the code you have to write, and there's a minimum (a
> substantial size, at that) we'll be expecting.  But the more code you
> can get from elsewhere, the better the product you'll produce this
> summer!
>
>
> Footnotes:
> [1]  The others, of course, are financial support for a student
> getting practical experience in software development, concentrating on
> coding, and development of worthwhile software for the mentoring org.
>



-- 
Abhilash Raj