[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Abhilash Raj writes: This is a list of topics that probably needs to be discussed in detail again. I tried to mention in breif about the discussions in past personally with a someone or on mm-dev list. Please ignore the topics which you feel has already reached a inference. It is a long mail though. * How to ensure the keys belong the email it says it does? This is not in scope for your project. Key upload is for bootstrapping strong authentication, therefore you should assume there is no strong authentication to authenticate the key upload. Man-in- the-middle attacks on the key upload mechanism are *way* above your pay grade. * Inline pgp should be supported or not? Although its not included in one the best practices but some people still use it for the purpose of signing only a part of the email. It depends on how it gets used. If there are MUAs that do this without consulting the user, then we should support it eventually. If it requires a user's guidance to get that result, then we can just tell them Don't do that. You should give a reference for not best practice. * How to handle partial multipart/signed messages? In previous discussion it was pointed out that we should strip off the parts till we actually arrive at a point where the signature verifies all the text and then send that part to the subscribers. Other options were to discard these kind of email or let the owner decide what he wants. I think we should handle it. Among other things, if you want the originator headers signed, I would think the easiest way to achieve that would be to send a signed message/rfc822 part. * Should mailman keep the signature of sender before signing or strip if off? Needs to be an option. By default, the sender's signature should be kept so that recipients who know the sender well enough to have his key can verify it. This may also help with catching key fraud. But as you say it could be used to identify a poster, and that might be bad in some contexts. * Should we make the sending of signed copies of email default? We can introduce an option to send signed email by default for those who want may verify the email, but is there a point in sending singed email when the mails received are not signed? Or this could be a good point? I don't understand what you're suggesting. I think the list should be capable of signing mail itself, even if incoming mail is not signed, yes. For example, posting may only be allowed by the list owner from localhost, and signing is a convenience. * Email interface to manage keys? Mailman has a set of email commands to process the requests for subscription, change password and many other things over email without a web interface, so to allow managing keys over email we could allow receiving signed emails with new keys and command to add them, the confirmation mail for the new key will then be sent to the same address but would expect a signed reply from the new key. Seems reasonable as an extension if you have time. * How are we actually using the web-of-trust model of OpenPGP? We aren't. Simplistic rules like two signatures are not going to be good enough for anybody who cares. Writing a framework so that admins can configure the signature policy is also above your pay grade. You should consider providing hooks for such validation, and maybe a proof of concept implementation to hook into it. Something like a key is considered valid if it is signed by the list-owner. About the implementation I decided to take up with the processing of email part first and then setting up the PKI for the users. The flow would be something like this: * the message is queued in incoming queue * the incoming runner wakes up, finds the message and calls a few functions to verify the signature of the message(assuming the function already has public key of the user from somewhere) I think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking. * If the message signature is found to be valid the message is then passed on to onther runners as usual (without stripping of the signature as per my assumption till now, need discussion on this) else it is dropped or bounced depending on the state of verification( like if the signature is older we can inform the sender as the delay may have been due to smtp deliver and simply drop the message if the signature is verified to be wrong). * Now a valid signature would be a signature signed within 4 days(default and configurable by list owner) from when mailman receives the email.(Is there someway to also check if the signature was previously sent on the list? so that we can block that also?) Here and in the previous
[Mailman-Developers] Wiki Migration Update
Hello, It's been a couple of months or so since my last update, and I finally got round to doing some more work on the content migration from Confluence to MoinMoin. As always, the results can be found here: http://mmwiki.boddie.org.uk/ At the moment, I'm still using the archived content from April 2013, and I took the opportunity this time round to fix various parsing and translation issues, particularly with the Confluence wiki markup (not the XHTML variant that the most recent revisions of pages use), also reworking some fairly fundamental mechanisms involved in parsing the wiki markup. Some previously mentioned fixes have been made: http://mmwiki.boddie.org.uk/COM/Organizations_that_use_Mailman (Anchors are now generated for the headings.) Some support for macros now exists, such as for the anchor, color and toc macros. Meanwhile, some things wait for more time and energy to be spent on them: Author information is still not preserved in the page import process, but this will be tested in future. The way comments are presented on pages still needs improving. It might also be nice to have a list of attachments on pages that have them, and I will take a look to see how Confluence tends to present such things. And some things won't get fixed until the hosting is changed, such as for pages ending in a question mark. As I have mentioned previously, the source code for the converter can be found here: http://hgweb.boddie.org.uk/ConfluenceConverter/ Please take a look at your favourite pages and let me know where improvements can be made to the conversion process. Paul ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Stephen's already given a very good response, so I'll just add a few more thoughts. On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote: * How to ensure the keys belong the email it says it does? One method proposed for this was to send a confirmation email to the email address, but what if the email is intercepted in between and the attacker confirms the sign up of the person he is trying to impersonate? Or this is a problem that can be solved with SSL and is not of our concern? One thing you could do is to send a confirmation message encrypted to that public key. You'd have to make sure that the confirmation token is *only* in the encrypted part (e.g. you could not include the token in the Subject header as we currently do for convenient just hit reply functionality). The point is that if Mailman has the public key, because they user just uploaded it, then the intended recipient must have the private key. If you encrypt the confirmation token to this public key, then the recipient's private key should be able to decrypt it. An evil interceptor wouldn't have that private key and thus would not be able to hijack anything. * Inline pgp should be supported or not? Probably not as a first step. PGP/MIME will be easier to support so do that first. As Stephen suggests, a survey of popular MUAs might be useful. My own (Claws Mail) supports them both, though I'm not sure which is default. I certainly use and prefer PGP/MIME. * Should mailman keep the signature of sender before signing or strip if off? You'll want to look at the IMailingList.anonymous_list flag. I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module. Which is where I think I should first start from. I was looking for a python wrapper for gnupg and found two options: [python-gnupg][2] and [gnupg-interface][3]. GnuPG-Interface was what was used in pgp-smime patch for mailman 2.1.5. I don't have much idea about waht should be used, will post on mailman-developers. Please use python-gnupg. I've been using it lately for a different project and I think it's very solid, with a nice API. Plus, it's actively maintained by a good developer who is responsive to bugs and feature requests. Plus, it's Python 3 compatible. :) I think it does make sense to put some primitives in a utilities/gpg.py module. The things that should go in here are probably higher level APIs that Mailman itself will find useful. Be sure that anything that goes in here has a unit test (at least) and possibly a doctest. About the outgoing messages i was thinking if we can create a signing queue and sign runner which simply signs each message with list's private-key and then the message moves on to outgoing queue where it can be delivered without any furthur changes. Any ideas about this? I'm with Stephen here, I don't think a separate queue is required. A new queue implies another runner, which means another process that must be managed. Signing isn't *that* much of a bottleneck that adding it will gum up the works too much. I think it would be okay to sign the message once for all recipients, even if we're doing personalization. The personalized parts will have to go in the unsigned bits though (e.g. the headers and any user-specific footer parts). If not, then the outgoing signatures will have to be added by the mta component so that it signs the final message before it's sent to the upstream MTA for delivery. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On Jun 16, 2013, at 01:48 AM, Stephen J. Turnbull wrote: * the message is queued in incoming queue * the incoming runner wakes up, finds the message and calls a few functions to verify the signature of the message(assuming the function already has public key of the user from somewhere) I think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking. Right. Remember that all the incoming runner does[*] is take a message that's already been parsed, and send it through the posting chain. That's the process whereby the message and its metadata flow through rules to determine whether the post is allowed. Clearly, signature checking should occur in a rule. This will also make it easier for you to test. * If the message signature is found to be valid the message is then passed on to onther runners as usual (without stripping of the signature as per my assumption till now, need discussion on this) else it is dropped or bounced depending on the state of verification( like if the signature is older we can inform the sender as the delay may have been due to smtp deliver and simply drop the message if the signature is verified to be wrong). The outcome of the signature checking rule is a boolean result. There will be an action associated with that. Because of the way links and rules work, the action is only taken if the rule hits. This means that I think the rule should probably return True if the message is *unsigned* and the action in that case is to jump to one of the Hold, Reject, or Discard chains (depending on a configuration variable - but we can discuss this). If the rule misses (i.e. returns False) then it means the signature was valid and rule processing just continues on. I know this is a little backwards, but it's probably the best match for the current rule/chain model. Maybe. Again you should check current style. I Think what you propose is OK, as Rules and Handlers can live in the same file since they are distinguished by their signatures. But I forget exactly how Barry organizes this stuff. Currently there are separate directories for rules and handlers. For now, it's best to follow that model. -Barry [*] It also creates IAddress records for any email addresses it's never seen before, but that's besides the point under discussion. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
