From minfrin at sharp.fm  Sat Jun  1 15:08:14 2013
From: minfrin at sharp.fm (Graham Leggett)
Date: Sat, 1 Jun 2013 15:08:14 +0200
Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6
In-Reply-To: <51A542AC.5060908@msapiro.net>
References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm>
	<51A2BF67.5070506@msapiro.net>
	<F17EA949-77FC-41B6-B219-9EAD6B84078C@sharp.fm>
	<51A379E5.3000802@msapiro.net>
	<042346EE-2784-40CA-BD6A-4B458D6A4CD2@sharp.fm>
	<51A542AC.5060908@msapiro.net>
Message-ID: <CF36B06D-0A12-4F07-9A55-B5F6BC02A7E3@sharp.fm>

On 29 May 2013, at 1:50 AM, Mark Sapiro <mark at msapiro.net> wrote:

> Actually, that patch is not what's required. The comment is wrong.
> @hostname is required for all vhosts lists regardless of the host name
> in the URL or the setting of VIRTUAL_HOST_OVERVIEW.
> 
> A correct patch is attached.

I will give this a try and confirm.

> As for the patch below, I see what you're trying to do, but I'm nervous
> about untended consequences of creating lists in domains not in
> VIRTUAL_HOSTS. I think the patch should be OK, but as I say, I'm nervous
> about it.
> 
> I will definitely commit the attached patch, and I'll think about the
> other. Do you have any motivation for it other than just not wanting to
> bother with adding add_virtualhost() to mm_cfg.py?

For me it causes a number of showstoppers, the first is that we can't automate the creation of the mailing lists in our environment, where running a command is easy but editing a shared system config file is hard. Over and above that we are forced to host the sites on separate virtual hosts, which in turn requires multiple digital certificates for us instead of just one. It also adds significant complexity to our environment, instead of keeping life simple for us.

I chose the VIRTUAL_HOST_OVERVIEW flag because it was already there and it seemed a sensible alignment, but I could change it to add an additional flag to control this.

Regards,
Graham
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4365 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130601/992bd308/attachment.bin>

From terri at zone12.com  Tue Jun  4 06:55:23 2013
From: terri at zone12.com (Terri Oda)
Date: Mon, 03 Jun 2013 22:55:23 -0600
Subject: [Mailman-Developers] Systers+Mailman GSoC introductions
Message-ID: <51AD733B.205@zone12.com>

Hi all,

This is a "now you all have each other's email addresses" email 
introduction.

Rose and Meflin are the org admins for Systers.

The rest of you are the Mailman mentors.

As we discussed, some of the folk from Mailman will be helping with the 
mentoring for Systers, and Rose would like to sort out how best to do 
this and make sure you're all in touch with your students. Rose says 
she's away for a couple of days and meflin's getting on a plane 
tomorrow, so probably this email is a bit early, but I didn't want to 
forget.

Rose: we should probably get all the mailman mentors cross-listed as 
systers mentors so that they can see the students' original proposals 
and to make melange paperwork easier.  Unless you have some serious 
objection, Meflin and I can probably arrange that.

Mailman mentors:

If you want to sign up for the systers-dev mailing list, here's the link:
http://systers.org/mailman/listinfo/systers-dev

I would like to encourage all the systers students to also sign up for 
mailman-developers, but I haven't pushed them to do that yet. When you 
talk to your specific students, please feel free to do so.

I'm having some trouble reading Rose's email, but I believe the mentors 
Rose suggested are below:

Admin Essay
Student: Julia P.
Systers Mentors: Rose, Promita

Admin dlist script
Student: Ioana
Systers Mentors: Anna, Meflin

Selenium Testing
Student: Olga
Systers Mentors: Mayank, Danielle, Lynn

RSS Feed
Student: Joanna
Systers Mentors: Joanna, Nicki
Mailman Mentor: Wacky  (We may want Aurelien in on this too since it's 
going to need integration with hyperkitty)

UI member Area:
Student: Shanu(Dardie)
Systers Mentor: Danielle,
Mailman Mentors: Aurelien, Stephen

UI MM3 design
Student: Sneha P.
Systers Mentor: Lynn
Mailman Mentors: Florian, Terri

Do feel free to rearrange yourselves if necessary, and I expect just 
like we do with Mailman that you'll all feel free to mentor other 
students when it's helpful to do so.

  Terri

From terri at zone12.com  Tue Jun  4 07:08:13 2013
From: terri at zone12.com (Terri Oda)
Date: Mon, 03 Jun 2013 23:08:13 -0600
Subject: [Mailman-Developers] Systers+Mailman GSoC introductions
In-Reply-To: <51AD733B.205@zone12.com>
References: <51AD733B.205@zone12.com>
Message-ID: <51AD763D.4000504@zone12.com>

*sigh* And this is what I get for sending email while on painkillers.  
My apologies, all!

  Terri

From mark at msapiro.net  Fri Jun  7 23:04:28 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 07 Jun 2013 14:04:28 -0700
Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6
In-Reply-To: <CF36B06D-0A12-4F07-9A55-B5F6BC02A7E3@sharp.fm>
References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm>
	<51A2BF67.5070506@msapiro.net>
	<F17EA949-77FC-41B6-B219-9EAD6B84078C@sharp.fm>
	<51A379E5.3000802@msapiro.net>
	<042346EE-2784-40CA-BD6A-4B458D6A4CD2@sharp.fm>
	<51A542AC.5060908@msapiro.net>
	<CF36B06D-0A12-4F07-9A55-B5F6BC02A7E3@sharp.fm>
Message-ID: <51B24ADC.9070900@msapiro.net>

On 06/01/2013 06:08 AM, Graham Leggett wrote:
> On 29 May 2013, at 1:50 AM, Mark Sapiro <mark at msapiro.net> wrote:
> 
>> Actually, that patch is not what's required. The comment is wrong.
>> @hostname is required for all vhosts lists regardless of the host name
>> in the URL or the setting of VIRTUAL_HOST_OVERVIEW.
>>
>> A correct patch is attached.
> 
> I will give this a try and confirm.


I have committed this to my branch at
<http://launchpad.net/~msapiro/mailman/vhost/>.


>> As for the patch below, I see what you're trying to do, but I'm nervous
>> about untended consequences of creating lists in domains not in
>> VIRTUAL_HOSTS. I think the patch should be OK, but as I say, I'm nervous
>> about it.


After giving it more thought, I committed that one too plus a merge of
the latest head of the 2.1 branch.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From raj.abhilash1 at gmail.com  Sat Jun 15 07:42:19 2013
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Sat, 15 Jun 2013 11:12:19 +0530
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
	Integration
Message-ID: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>


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?

  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?

* 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.

* 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.

* Should mailman keep the signature of sender before signing or strip if off?

  In previous discussions it was mentioned that user's signature can be kept as
  it is and the list re-signs the message before sending the subscribers as
  subscribers may want to confirm if the email was originally sent by the user in
  the From address. But there might be a case of anonymous list where identity
  of the sender should not be revealed and is only verified that any one the
  members sent the email. So can we introduce this as an option?

  About introducing options I agree to a point mentioned in the
  mailman-pgp-smime patch for mailman where it says that although there are lots
  of ways we can allow the list owner to configure a list, we should only
  provide minimal options to avoid unexpected scenarios where the list's
  security is compromised due to lots of options.

* 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?

* 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.

* How are we actually using the web-of-trust model of OpenPGP? 

  Should there be any restrictions on the key to implement the
  web-of-trust model which advocates for the authenticity of the key
  provided by the user? Something like it must be signed by 2 or 3
  people or anything like that?


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)
* 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?)
* After that the message passes on to various other queue and runners as
  usual and when finally it arrives at outgoing runner it again calls a
  few functions to sign the message and send it to MTA.

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.

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?

--
Abhilash Raj

From stephen at xemacs.org  Sat Jun 15 18:48:34 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 16 Jun 2013 01:48:34 +0900
Subject: [Mailman-Developers] A list of discussion topics: GSoC
	OpenPGP	Integration
In-Reply-To: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
Message-ID: <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>

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 point I don't think you should be adding
policy options yet.  I don't see why we need to consider dates other
than the issue of expired keys.  Similarly for revoked keys, but of
course we can't tell that very easily.

 > * After that the message passes on to various other queue and runners as
 >   usual and when finally it arrives at outgoing runner it again calls a
 >   few functions to sign the message and send it to MTA.

Similarly to the above, I don't think this should be done in the
outgoing runner, but rather in the Handler pipeline.

 > I think the function to prase message, check signature, resign message
 > could be there in utilities as a gpg.py module.

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.

 > 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?

Queues imply storage.  I don't know if we are thinking about any
threat models in which the attacker could change content after
validation of the poster's signature and before resigning as the list,
but you want to be careful about proliferating queues.

Steve

From paul at boddie.org.uk  Sat Jun 15 21:09:58 2013
From: paul at boddie.org.uk (Paul Boddie)
Date: Sat, 15 Jun 2013 21:09:58 +0200
Subject: [Mailman-Developers] Wiki Migration Update
Message-ID: <201306152109.58502.paul@boddie.org.uk>

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

From barry at list.org  Sat Jun 15 23:45:57 2013
From: barry at list.org (Barry Warsaw)
Date: Sat, 15 Jun 2013 17:45:57 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
Message-ID: <20130615174557.4f196779@anarchist>

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

From barry at list.org  Sat Jun 15 23:54:30 2013
From: barry at list.org (Barry Warsaw)
Date: Sat, 15 Jun 2013 17:54:30 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20130615175430.18c2fec7@anarchist>

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.

From stephen at xemacs.org  Sun Jun 16 08:42:59 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 16 Jun 2013 15:42:59 +0900
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <20130615175430.18c2fec7@anarchist>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130615175430.18c2fec7@anarchist>
Message-ID: <87ip1e5zf0.fsf@uwakimon.sk.tsukuba.ac.jp>

Not in GSoC scope, this is direct to Barry (and anybody else,
including GSoC students of course, interested in core).

Barry Warsaw writes:

 > I know this is a little backwards, but it's probably the best match
 > for the current rule/chain model.

I have a smallish problem with this model.  Specifically, for a list
with a maximum size, I think it's probably desirable to do any MIME
part stripping *before* the size test.  But this doesn't fit the
chain(s) -> pipeline model AFAICS.  I suspect there are probably other
such cases where a bit of preprocessing would be useful, in particular
if we implement a reencryption facility as Abhilash originally
proposed.



From joostvb-mailman-developers at mdcc.cx  Sun Jun 16 10:13:44 2013
From: joostvb-mailman-developers at mdcc.cx (Joost van =?utf-8?Q?Baal-Ili=C4=87?=)
Date: Sun, 16 Jun 2013 10:13:44 +0200
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20130616081344.GP504@beskar.mdcc.cx>

Hi,

On Sun, Jun 16, 2013 at 01:48:34AM +0900, Stephen J. Turnbull wrote:
> 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.
> 
<snip>
>  > * 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".

Indeed, that could work.  Another way to deal with it could be: "a key is
considered valid if it is imported in the trusted keyring of the current list".
And declare deciding wether to import out of the scope of the project.

Bye,

Joost

-- 
Ich will in euch einen neuen Geist geben;  Ich werde aus eurem Fleisch das
Herz aus Stein nehmen, und will euch geben ein Herz aus Fleisch. --Ez 36,2
http://mdcc.cx/      ?      http://ad1810.com/      ?      Eindhoven, .nl

From stephen at xemacs.org  Sun Jun 16 11:02:20 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 16 Jun 2013 18:02:20 +0900
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <20130616081344.GP504@beskar.mdcc.cx>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130616081344.GP504@beskar.mdcc.cx>
Message-ID: <87bo765syr.fsf@uwakimon.sk.tsukuba.ac.jp>

Joost van Baal-Ili? writes:

 > Indeed, that could work.  Another way to deal with it could be: "a
 > key is considered valid if it is imported in the trusted keyring of
 > the current list".  And declare deciding wether to import out of
 > the scope of the project.

I think that we necessarily have to trust the list's keyring, that's
what it's there for.  The question is how do keys get into the trusted
list.

What I had in mind was that "signed-by-list-owner" would be a reason
to import automatically.  The model I have in mind is that signing
Mr. A's key means the list owner is willing to vouch for authenticity
of that key to others, meaning he know Mr. A (including where to find
him if he cheats).  This is probably good enough for lists where the
3-way handshake (subscribe, request confirmation, confirm) is good
enough authentication of the mail address itself.

On the other hand, it's still not a strong authentication in the sense
Abhilash wants.  Mr. A might have tricked the list owner into signing
a throw-away key which will be used to spoof Mr. B's email address.  A
similar trick would defeat Barry's scheme of sending the one-time key
in encrypted form, if the bad guy both submits the PGP key and can
intercept Mr. A's mail.  Both of these schemes have some merit in that
there's a very short window of opportunity for the bad guy.  Once an
authentic key has been linked to an address, authentication is very
strong.





From rkw at dataplex.net  Sun Jun 16 13:21:03 2013
From: rkw at dataplex.net (Richard Wackerbarth)
Date: Sun, 16 Jun 2013 06:21:03 -0500
Subject: [Mailman-Developers] Systers VM for Mailman Development
In-Reply-To: <CAGbY=uyV+DpuEe=NM-RtfSnmDB2Dk_cokimRsj8uMMamKKOAvA@mail.gmail.com>
References: <9DD3C7D5-2125-42A4-A40E-C2FBD235B841@dataplex.net>
	<CAGbY=uyV+DpuEe=NM-RtfSnmDB2Dk_cokimRsj8uMMamKKOAvA@mail.gmail.com>
Message-ID: <15F76539-E2D5-43F5-9A52-38167627BEF6@dataplex.net>

Hi,

You have provided me with EXACTLY the information that I requested.

To operate in this mode, I recommend the following:
1) Read enough about Vagrant to be able to "freeze" an image of the VM and use that as a base for your actual work.
That way, you can work through the initial setup of your own customized installation and freeze the result, That way you won't need to repeat those steps every time you want to make a new VM. Then, by working in an expendable copy of the VM, when you "mess up" (and you will :) ), you can just toss it away (vagrant destroy) and start over with a clean copy.

2) Whether you are working in a VM, or directly on your host machine, I strongly recommend the use of virtualenv and virtualenvwrapper. (I like the added functions of the wrapper. But the important concept is the use of the virtual environments)
 Virtual environments are like a "poor man's" virtual machine but they don't encounter the overhead of a virtual machine. They allow you to have independent sets of python and python libraries installed. Thus one program can use a different version of a library without affecting other programs.

In my setup, I use a separate virtual environment to represent each logical machine that runs a part of the mailman system.
Thus my mail handler (the "core" part of mailman) is in a separate virtual environment from the web server (postorius).

3) When it comes to development, the various python modules can be divided into three groups.
  a) The code that you are developing
  b) Other code that is under development but for which you want to use a pre-release version. (or any "source" distribution)
  c) Additional library functions upon which those parts depend.

For the vagrant virtual machine organization that you will be using:
Place the (c) routines in /vagrant and keep them under your SCM (version control).
You can have the (b) routines in the home directory on the virtual machine.
The (a) routines will be loaded into the site-packages for the individual virtual environments as a part of the installation process.

If you follow this layout, it will be easy to replace any of the various components whenever you desire.

Since we are new to working with Vagrant, a setup for the mailman project such as I describe is still a "work-in-progress".
Expect some revisions during the summer. However, they should not have any negative impact on your work because all of your code will be stored under the /vagrant mount point and can be moved readily from one virtual machine configuration to the next.

Now, for your code, I recommend that you start by having a separate folder for each of the virtual environments.
In my current setup, I have two virtual environments "VE-mailman" and "VE-webserver".
In your source, you can have:
/vagrant/webserver/my_django_app1/
/vagrant/webserver/my_django_app2/
/vagrant/webserver/my_website/
/vagrant/mailman/some_addition_to_mm-core/

Of course, depending on just what your project requires, you may not need all of these parts.

Eventually, I would expect to see a setup script that is able to use this layout to automate the building of a suggested installation script.

I hope that this helps.

Feel free to ask questions and make suggestions to improve this setup.

Richard

On Jun 15, 2013, at 10:44 PM, Julia Proft <jproft at conncoll.edu> wrote:

> Hi Richard,
<snip>
> this is my first time using virtual machines in development, and I'm figuring it out as I go! Right now, my game plan is to edit on my Windows host, and I'll keep those files in a shared folder that is accessible through the VM... then I can execute the files on the VM.
<snip>
> Best,
> Julia

> On Sat, Jun 15, 2013 at 3:35 PM, Richard Wackerbarth <rkw at dataplex.net> wrote:
> Hi, Julia.
> 
> I'm Richard "Wacky" Wackerbarth, one of the Mailman developers and a Mentor for GSoC.
> 
> I notice that, in a discussion on the systems-dev mailing list, you indicated that your host machine is running "Windows 7".  Since that is one of the least "Unix friendly" environments, I was wondering just how you utilize the Virtual Machine images in your development cycle.
> 
> It appears that the machines are set up to be "an appliance" (which is great if all you want to do is deploy it). However, using ssh to communicate in a terminal window isn't very friendly for developers.
> 
> So I'm wondering just where you store your code that is under development, how do you edit it, and on what host you execute it?
<snip>

From barry at list.org  Sun Jun 16 17:29:50 2013
From: barry at list.org (Barry Warsaw)
Date: Sun, 16 Jun 2013 11:29:50 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <87ip1e5zf0.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130615175430.18c2fec7@anarchist>
	<87ip1e5zf0.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20130616112950.60606392@anarchist>

On Jun 16, 2013, at 03:42 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > I know this is a little backwards, but it's probably the best match
> > for the current rule/chain model.
>
>I have a smallish problem with this model.  Specifically, for a list
>with a maximum size, I think it's probably desirable to do any MIME
>part stripping *before* the size test.  But this doesn't fit the
>chain(s) -> pipeline model AFAICS.  I suspect there are probably other
>such cases where a bit of preprocessing would be useful, in particular
>if we implement a reencryption facility as Abhilash originally
>proposed.

It's a valid complaint.  What I've suggested in the past is that a rule can do
some *nondestructive* processing of a message before it makes its decision.
The rule would either throw out the results of the processing (possibly
leading to duplication of work) or would cache the results, e.g. in the
metadata dictionary (possibly leading to a rather large pickle/in-memory
data).

It's not great, but I still like the separation of concerns and the general
concept that rules don't modify the message.  To do otherwise introduces
ordering dependency on the rules, which I really want to avoid.  Ordering
dependency on handlers can't be helped I think.

I'm certainly open to ideas here, especially if this becomes more prevalent.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130616/258e87ed/attachment.pgp>

From mark at msapiro.net  Sun Jun 16 17:32:49 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 16 Jun 2013 08:32:49 -0700
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <20130615174557.4f196779@anarchist>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<20130615174557.4f196779@anarchist>
Message-ID: <51BDDAA1.2060007@msapiro.net>

On 06/15/2013 02:45 PM, Barry Warsaw wrote:
> 
> On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote:
> 
>> * 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.


I think Thunderbird/EnigMail uses inline pgp by default, but PGP/MIME
can be set as the default per account and is always available when
composing a message.

At one time EnigMail discouraged PGP/MIME as being supported by few
MUAs, but that caveat appears to have been removed from the current UI.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130616/74ff15bc/attachment.pgp>

From mark at msapiro.net  Sun Jun 16 17:43:26 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 16 Jun 2013 08:43:26 -0700
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <87ip1e5zf0.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130615175430.18c2fec7@anarchist>
	<87ip1e5zf0.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <51BDDD1E.3010501@msapiro.net>

On 06/15/2013 11:42 PM, Stephen J. Turnbull wrote:
> 
> Barry Warsaw writes:
> 
>  > I know this is a little backwards, but it's probably the best match
>  > for the current rule/chain model.
> 
> I have a smallish problem with this model.  Specifically, for a list
> with a maximum size, I think it's probably desirable to do any MIME
> part stripping *before* the size test.  But this doesn't fit the
> chain(s) -> pipeline model AFAICS.


FYI, on my production server (MM 2.1 - well actually 2.2+ ;) I reorder
the GLOBAL_PIPELINE to put MIMEDel before Hold for exactly this reason.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From barry at list.org  Sun Jun 16 17:43:48 2013
From: barry at list.org (Barry Warsaw)
Date: Sun, 16 Jun 2013 11:43:48 -0400
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <201306152109.58502.paul@boddie.org.uk>
References: <201306152109.58502.paul@boddie.org.uk>
Message-ID: <20130616114348.5ca4d015@anarchist>

On Jun 15, 2013, at 09:09 PM, Paul Boddie wrote:

>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/

It's looking great Paul.  I really appreciate your continued efforts here.
I'd like to hear especially from Mark and the other top wiki editors what they
think is still necessary before we can pull off the migration.  We all know it
won't be perfect, but I think it has to be just good enough that a manual
cleanup is tractable.  A migration would provide a good opportunity to do some
much needed gardening. ;)

Here are some of my thoughts:

* Once we migrate we can probably get rid of the spaces.  I think that's a
  Confluence-ism that doesn't translate as well to Moin.  That should be easy
  enough to do manually, right?

* We'll want a moderate amount of theming to be more consistent with the web
  site, but the latter also is in dire need of an update.

* The top link on the FAQ page doesn't work.
  http://mmwiki.boddie.org.uk/DOC/Frequently%20Asked%20Questions

* Only the FAQ 4 page has sub-FAQ numbers.  (BTW, do you know of any Moin
  feature to make creating and managing a FAQ nicer?)

* How will we control wiki spam on the new site?  Right now, we allow anyone
  to sign up and read, but they must request write access.  When they do, we
  add their userid to a special group that has write to any wiki page (except
  the currently unused private pages).  Can we have the same setup for Moin?
  I think it's *probably* okay to just have people re-request write access
  after a migration (no need to automate the user/group migration I think).

It seems to me the Moin wiki is pretty darn close.  If Mark and others agree,
I can start the ball rolling to request the necessary resources and DNS
shuffles.

Cheers,
-Barry

From stephen at xemacs.org  Sun Jun 16 18:52:52 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 17 Jun 2013 01:52:52 +0900
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <20130616112950.60606392@anarchist>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130615175430.18c2fec7@anarchist>
	<87ip1e5zf0.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130616112950.60606392@anarchist>
Message-ID: <874ncy576j.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > It's a valid complaint.  What I've suggested in the past is that a
 > rule can do some *nondestructive* processing of a message before it
 > makes its decision.  The rule would either throw out the results of
 > the processing (possibly leading to duplication of work) or would
 > cache the results, e.g. in the metadata dictionary (possibly
 > leading to a rather large pickle/in-memory data).

Yeah, I was afraid you'd say something like that.  This could be quite
expensive in terms of duplicating work for encryption, but I guess we
cross that bridge when we come to it.

From paul at boddie.org.uk  Sun Jun 16 20:17:01 2013
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 16 Jun 2013 20:17:01 +0200
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <20130616114348.5ca4d015@anarchist>
References: <201306152109.58502.paul@boddie.org.uk>
	<20130616114348.5ca4d015@anarchist>
Message-ID: <201306162017.01384.paul@boddie.org.uk>

On Sunday 16 June 2013 17:43:48 Barry Warsaw wrote:
> On Jun 15, 2013, at 09:09 PM, Paul Boddie wrote:
> >
> >http://mmwiki.boddie.org.uk/
>
> It's looking great Paul.  I really appreciate your continued efforts here.
> I'd like to hear especially from Mark and the other top wiki editors what
> they think is still necessary before we can pull off the migration.  We all
> know it won't be perfect, but I think it has to be just good enough that a
> manual cleanup is tractable.  A migration would provide a good opportunity
> to do some much needed gardening. ;)

Indeed. Thanks for the feedback!

> Here are some of my thoughts:
>
> * Once we migrate we can probably get rid of the spaces.  I think that's a
>   Confluence-ism that doesn't translate as well to Moin.  That should be
> easy enough to do manually, right?

The only apparent purpose of the spaces is to separate the content and to 
prevent name collisions, but I'm not sure there are any such collisions. 
Maybe I can check this.

> * We'll want a moderate amount of theming to be more consistent with the
> web site, but the latter also is in dire need of an update.
>
> * The top link on the FAQ page doesn't work.
>   http://mmwiki.boddie.org.uk/DOC/Frequently%20Asked%20Questions

Yes, that page has a name ending in a question mark, and the way I host this 
publicly doesn't like that. It's a bug in mod_rewrite, and if I host it on my 
own local Apache instance with full control over the configuration, I don't 
get this problem. It will go away in future, I promise. :-)

Actually, I could have changed the page title generation to remove trailing 
question marks for this exercise; I already shorten page names where the 
filesystem would otherwise be upset (Moin needing to use the page names when 
storing pages).

> * Only the FAQ 4 page has sub-FAQ numbers.  (BTW, do you know of any Moin
>   feature to make creating and managing a FAQ nicer?)

I'm sorry but I don't quite follow the first sentence here. All of the pages 
should show a list of questions in their respective section, but I see that 
only section 4 has numbered pages. Is that what you meant? The page names I 
take straight from Confluence, and you can see the same phenomenon in the 
existing wiki:

http://wiki.list.org/display/DOC/Frequently+Asked+Questions

Of other Moin sites providing FAQs, I can think of the Mercurial Wiki:

http://mercurial.selenic.com/wiki/FAQ

Here, they use the Include macro to bring in subpages providing each section, 
and the Moin TableOfContents macro is smart enough to see all the included 
content and make a huge TOC. They could go further and also provide edit 
links when including content: then, if anyone wanted to edit a section or a 
question, they would be able to find the link for the subpage and do so; 
editing the main page only really permits editing of the Include macros and 
little else, as seen in the raw text of the page:

http://mercurial.selenic.com/wiki/FAQ?action=raw

As you can see from the existing translation of the Mailman Wiki, it's 
possible to include many pages without having to name them all; take a look 
at the last line of the following, which is used to drag in all the comments 
on the page:

http://mmwiki.boddie.org.uk/COM/Home?action=raw

The ordering seems to be fixed on the page names concerned, however, making it 
somewhat awkward if you prefer a different ordering, but we could always 
provide a variant of the Include macro that supported other ordering 
capabilities, I imagine.

> * How will we control wiki spam on the new site?  Right now, we allow
> anyone to sign up and read, but they must request write access.  When they
> do, we add their userid to a special group that has write to any wiki page
> (except the currently unused private pages).  Can we have the same setup
> for Moin? I think it's *probably* okay to just have people re-request write
> access after a migration (no need to automate the user/group migration I
> think).

Moin is very flexible about access control, so we can almost certainly support 
what is needed. As for registration, I think there are extensions that 
require people to verify themselves using e-mail - the Debian Wiki may be 
using this, I think - and it's probably completely feasible to support this 
kind of mechanism.

As for migration, I haven't looked into this, but I don't see too many 
problems at least replicating the Confluence accounts, even if we can't 
migrate all the details.

(I think it's interesting to consider issues of authentication, and 
coincidentally with respect to the Summer of Code work, I've been playing 
with PGP-signed/encrypted interactions with Moin. So I look forward to seeing 
what people come up with around such interactions with Mailman.)

> It seems to me the Moin wiki is pretty darn close.  If Mark and others
> agree, I can start the ball rolling to request the necessary resources and
> DNS shuffles.

My main concern is that I've missed some weird markup behaviour and that we 
end up with pages where the markup is completely wrong throughout the history 
of the page (both Confluence markup and the XHTML variant that Confluence 4 
and later use). But I'd like to think that I'm reaching the second half of 
the exercise at the very least. ;-)

Paul

P.S. I can perhaps regenerate the site to work around the question mark issue, 
if you want. Then, all of the content should be navigable.

From barry at list.org  Mon Jun 17 17:13:01 2013
From: barry at list.org (Barry Warsaw)
Date: Mon, 17 Jun 2013 11:13:01 -0400
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <201306162017.01384.paul@boddie.org.uk>
References: <201306152109.58502.paul@boddie.org.uk>
	<20130616114348.5ca4d015@anarchist>
	<201306162017.01384.paul@boddie.org.uk>
Message-ID: <20130617111301.6c1b0c90@anarchist>

On Jun 16, 2013, at 08:17 PM, Paul Boddie wrote:

>> * Once we migrate we can probably get rid of the spaces.  I think that's a
>>   Confluence-ism that doesn't translate as well to Moin.  That should be
>> easy enough to do manually, right?
>
>The only apparent purpose of the spaces is to separate the content and to 
>prevent name collisions, but I'm not sure there are any such collisions. 
>Maybe I can check this.

I'd be surprised if there were any collisions.  Spaces seemed to be baked into
Confluence, but for our modest wiki I never really saw much value in them.

>> * We'll want a moderate amount of theming to be more consistent with the
>> web site, but the latter also is in dire need of an update.
>>
>> * The top link on the FAQ page doesn't work.
>>   http://mmwiki.boddie.org.uk/DOC/Frequently%20Asked%20Questions
>
>Yes, that page has a name ending in a question mark, and the way I host this 
>publicly doesn't like that. It's a bug in mod_rewrite, and if I host it on my 
>own local Apache instance with full control over the configuration, I don't 
>get this problem. It will go away in future, I promise. :-)

Cool.  That's another thing to take notice of: are there any deployment issues
we'd need to inform the python.org admins of?  We already run a couple of
Moins on that infrastructure, so I'm hoping that it'll be pretty easy to bring
up another one.

>Actually, I could have changed the page title generation to remove trailing 
>question marks for this exercise; I already shorten page names where the 
>filesystem would otherwise be upset (Moin needing to use the page names when 
>storing pages).

That's probably fine too.

>> * Only the FAQ 4 page has sub-FAQ numbers.  (BTW, do you know of any Moin
>>   feature to make creating and managing a FAQ nicer?)
>
>I'm sorry but I don't quite follow the first sentence here. All of the pages 
>should show a list of questions in their respective section, but I see that 
>only section 4 has numbered pages. Is that what you meant?

Yep.

>The page names I take straight from Confluence, and you can see the same
>phenomenon in the existing wiki:
>
>http://wiki.list.org/display/DOC/Frequently+Asked+Questions

Yay. ;)

>Of other Moin sites providing FAQs, I can think of the Mercurial Wiki:
>
>http://mercurial.selenic.com/wiki/FAQ
>
>Here, they use the Include macro to bring in subpages providing each section, 
>and the Moin TableOfContents macro is smart enough to see all the included 
>content and make a huge TOC. They could go further and also provide edit 
>links when including content: then, if anyone wanted to edit a section or a 
>question, they would be able to find the link for the subpage and do so; 
>editing the main page only really permits editing of the Include macros and 
>little else, as seen in the raw text of the page:
>
>http://mercurial.selenic.com/wiki/FAQ?action=raw
>
>As you can see from the existing translation of the Mailman Wiki, it's 
>possible to include many pages without having to name them all; take a look 
>at the last line of the following, which is used to drag in all the comments 
>on the page:
>
>http://mmwiki.boddie.org.uk/COM/Home?action=raw
>
>The ordering seems to be fixed on the page names concerned, however, making
>it somewhat awkward if you prefer a different ordering, but we could always
>provide a variant of the Include macro that supported other ordering
>capabilities, I imagine.

Oh, I'm just pining for Guido's old FAQwizard.  It was nice to be able to just
add questions and answers, with a minimal amount of categorization and
ordering, and then have them all collected and formatted correctly.  It's not
that big of a deal - I was mostly wondering how other projects maintained
their FAQ.

>> * How will we control wiki spam on the new site?  Right now, we allow
>> anyone to sign up and read, but they must request write access.  When they
>> do, we add their userid to a special group that has write to any wiki page
>> (except the currently unused private pages).  Can we have the same setup
>> for Moin? I think it's *probably* okay to just have people re-request write
>> access after a migration (no need to automate the user/group migration I
>> think).
>
>Moin is very flexible about access control, so we can almost certainly
>support what is needed. As for registration, I think there are extensions
>that require people to verify themselves using e-mail - the Debian Wiki may
>be using this, I think - and it's probably completely feasible to support
>this kind of mechanism.
>
>As for migration, I haven't looked into this, but I don't see too many 
>problems at least replicating the Confluence accounts, even if we can't 
>migrate all the details.

Sounds good, thanks.

>(I think it's interesting to consider issues of authentication, and 
>coincidentally with respect to the Summer of Code work, I've been playing 
>with PGP-signed/encrypted interactions with Moin. So I look forward to seeing 
>what people come up with around such interactions with Mailman.)

Me too!

>> It seems to me the Moin wiki is pretty darn close.  If Mark and others
>> agree, I can start the ball rolling to request the necessary resources and
>> DNS shuffles.
>
>My main concern is that I've missed some weird markup behaviour and that we 
>end up with pages where the markup is completely wrong throughout the history 
>of the page (both Confluence markup and the XHTML variant that Confluence 4 
>and later use). But I'd like to think that I'm reaching the second half of 
>the exercise at the very least. ;-)
>
>Paul
>
>P.S. I can perhaps regenerate the site to work around the question mark
>issue, if you want. Then, all of the content should be navigable.

That would be fantastic, thanks.  Let's wait for Mark's feedback and then we
can start thinking about next steps.

Cheers,
-Barry

From paul at boddie.org.uk  Mon Jun 17 17:57:58 2013
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 17 Jun 2013 17:57:58 +0200
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <20130617111301.6c1b0c90@anarchist>
References: <201306152109.58502.paul@boddie.org.uk>
	<201306162017.01384.paul@boddie.org.uk>
	<20130617111301.6c1b0c90@anarchist>
Message-ID: <201306171757.58724.paul@boddie.org.uk>

On Monday 17 June 2013 17:13:01 Barry Warsaw wrote:
>
> Oh, I'm just pining for Guido's old FAQwizard.  It was nice to be able to
> just add questions and answers, with a minimal amount of categorization and
> ordering, and then have them all collected and formatted correctly.  It's
> not that big of a deal - I was mostly wondering how other projects
> maintained their FAQ.

The FAQ wizard: those were the days! :-)

One thing I forgot about was the Python Wiki's "Asking for help" page, which 
seems to have been broken after the restoration of that wiki:

http://wiki.python.org/moin/Asking_for_Help

A similar thing is done by MoinMoin:

http://moinmo.in/MoinMoinBugs

The person with the question (or bug in the latter case) makes a new page 
using the form given for that purpose. They then fill out the template and 
save the page. The page will then appear in the list of subpages on the 
original page.

Again, this lacks control over things like ordering, and it's arguably one 
step too many - it would be better to just be able to write a question into a 
box and submit it - so perhaps something more sophisticated would be nice. I 
have been working on a forms solution for Moin, and it probably isn't quite 
ready, but maybe I can just finish it off and give it a spin.

Paul

From mark at msapiro.net  Mon Jun 17 18:22:55 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 17 Jun 2013 09:22:55 -0700
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <20130617111301.6c1b0c90@anarchist>
References: <201306152109.58502.paul@boddie.org.uk>
	<20130616114348.5ca4d015@anarchist>
	<201306162017.01384.paul@boddie.org.uk>
	<20130617111301.6c1b0c90@anarchist>
Message-ID: <51BF37DF.8070903@msapiro.net>

On 06/17/2013 08:13 AM, Barry Warsaw wrote:
> 
> That would be fantastic, thanks.  Let's wait for Mark's feedback and then we
> can start thinking about next steps.


I am traveling and visiting family through the end of the month and
haven't been following this too closely, but there is only one issue I'm
concerned about and that's URLs to FAQ pages in archived list mail.

It's not a show stopper. We had the same issue when we converted from
the FAQWizard, and it didn't seem to be a big deal, but here it is.

Every page (I think) in the wiki has three URLs.

E.g.
1. <http://wiki.list.org/display/DOC/Frequently+Asked+Questions>
2. <http://wiki.list.org/pages/viewpage.action?pageId=3604482>
3. <http://wiki.list.org/x/AgA3>

I gather that in the migration to Moin, the pages will have names/URLs
like 1. but with spaces instead of pluses. This is fine, and if
necessary a mapping from old to new URLs can be easily constructed.

Form 2. is trickier. Confluence seems to use somewhat arbitrarily either
1. or 2. in internal links, so form 2. is sometimes seen in list posts
referring to FAQ articles.

Form 3. is what Confluence calls "Tiny Link: (useful for email)" and is
available in the pages 'info' and (along with form 1.) in the "Link to
this Page" Tool dialog. I use this all the time in list posts referring
to FAQ articles.

I don't know what info is available in the Confluence dump, but it would
be nice to have at least the 'tiny link' and maybe the pageId info so
that mappings and maybe eventually redirections can be constructed to
get from the old URLs to the new pages.

As I said, I don't think it's a show stopper, but it would be helpful.

Regarding the article numbers appearing in section 4 only: in the
FAQWizard, all the articles were numbered. When Teri converted the
FAQWizard, she dropped the numbers from the page titles. This proved
controversial and Duncan Drury added them back, but only in section 4.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From paul at boddie.org.uk  Mon Jun 17 18:57:23 2013
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 17 Jun 2013 18:57:23 +0200
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <51BF37DF.8070903@msapiro.net>
References: <201306152109.58502.paul@boddie.org.uk>
	<20130617111301.6c1b0c90@anarchist> <51BF37DF.8070903@msapiro.net>
Message-ID: <201306171857.24041.paul@boddie.org.uk>

On Monday 17 June 2013 18:22:55 Mark Sapiro wrote:
>
> Every page (I think) in the wiki has three URLs.
>
> E.g.
> 1. <http://wiki.list.org/display/DOC/Frequently+Asked+Questions>
> 2. <http://wiki.list.org/pages/viewpage.action?pageId=3604482>
> 3. <http://wiki.list.org/x/AgA3>
>
> I gather that in the migration to Moin, the pages will have names/URLs
> like 1. but with spaces instead of pluses. This is fine, and if
> necessary a mapping from old to new URLs can be easily constructed.

I had imagined that browsers will convert to spaces in form 1, anyway, given 
that "+" is traditionally the encoding for a space, but it appears that 
Firefox may be encoding "+" and presenting the encoded URL to the server. 
Thus, the following fails:

http://mmwiki.boddie.org.uk/DOC/Frequently+Asked+Questions

Maybe some kind of rewrite rule could be used, or I could generate alias pages 
which redirect to the real pages.

> Form 2. is trickier. Confluence seems to use somewhat arbitrarily either
> 1. or 2. in internal links, so form 2. is sometimes seen in list posts
> referring to FAQ articles.

The page/version identifiers are used by the converter, and they even appear 
in the raw text of the Moin pages as a "pragma", but we'd probably extract 
all these correspondences and deploy some kind of mapping resource that takes 
an identifier and performs a redirect to the appropriate Moin page.

> Form 3. is what Confluence calls "Tiny Link: (useful for email)" and is
> available in the pages 'info' and (along with form 1.) in the "Link to
> this Page" Tool dialog. I use this all the time in list posts referring
> to FAQ articles.
>
> I don't know what info is available in the Confluence dump, but it would
> be nice to have at least the 'tiny link' and maybe the pageId info so
> that mappings and maybe eventually redirections can be constructed to
> get from the old URLs to the new pages.
>
> As I said, I don't think it's a show stopper, but it would be helpful.

I'm not sure these tiny links are in the Confluence dump, but if there's an 
algorithm to generate them, then maybe we can provide a similar mapping 
resource.

> Regarding the article numbers appearing in section 4 only: in the
> FAQWizard, all the articles were numbered. When Teri converted the
> FAQWizard, she dropped the numbers from the page titles. This proved
> controversial and Duncan Drury added them back, but only in section 4.

The history of such matters is always interesting. :-)

Paul

From barry at list.org  Mon Jun 17 20:19:06 2013
From: barry at list.org (Barry Warsaw)
Date: Mon, 17 Jun 2013 14:19:06 -0400
Subject: [Mailman-Developers] Wiki Migration Update
In-Reply-To: <201306171857.24041.paul@boddie.org.uk>
References: <201306152109.58502.paul@boddie.org.uk>
	<20130617111301.6c1b0c90@anarchist> <51BF37DF.8070903@msapiro.net>
	<201306171857.24041.paul@boddie.org.uk>
Message-ID: <20130617141906.1777e1ff@anarchist>

On Jun 17, 2013, at 06:57 PM, Paul Boddie wrote:

>I'm not sure these tiny links are in the Confluence dump, but if there's an 
>algorithm to generate them, then maybe we can provide a similar mapping 
>resource.

Just as a general feature request, it would be cool if Moin supported tiny
urls.  I use them in email too!

-Barry

From barry at list.org  Wed Jun 19 00:50:02 2013
From: barry at list.org (Barry Warsaw)
Date: Tue, 18 Jun 2013 18:50:02 -0400
Subject: [Mailman-Developers] GSOC Project Discussion
In-Reply-To: <27A1275F-B5CB-498B-AD18-4B84B1396642@dataplex.net>
References: <CAPkTf0Ktr+omV-Os72UGZqqG0AP3t3HuUHwX6fqwE=M+LkVOWg@mail.gmail.com>
	<87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CAPkTf0JTo0DKrYPz0qcHACkjpKUW3J32x=qZgbJouhO=iG-ZLQ@mail.gmail.com>
	<20130517161648.5691c17e@anarchist>
	<32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net>
	<20130530190721.014cf538@anarchist>
	<27A1275F-B5CB-498B-AD18-4B84B1396642@dataplex.net>
Message-ID: <20130618185002.09f7d32a@anarchist>

On May 30, 2013, at 06:37 PM, Richard Wackerbarth wrote:

>OK. Then a "roster" represents the distribution list for a "feed" of outgoing
>messages.  The "mailinglist" represents the reception point(s) for the
>incoming messages and the directives for handling the processing of those
>messages.
>
>The thing that hasn't been addressed is how an individual recipient can
>affect the processing of messages that are processed while he is a member of
>a roster.
>
>In particular, how do the "user settings" come into play?  Presumedly, a user
>can have different settings for each list to which he is subscribed.

Yes.  Keep in mind though that we have three data types that are associated
with a "user" (each of these are described by interfaces in the
mailman/interfaces directory).  Each email address the system knows about is
represented by an IAddress record.  An IUser record doesn't have much more
than a created_on date, a user_id, a display name, and a password, but it has
a number of abstract methods and attributes for convenience.

Addresses are usually, but not necessarily, linked to users in a many-to-one
relationship.  An address can have at most one user, but a user can have many
addresses.  A user can also have a preferred address.

IMember records represent subscriptions, and (loosely) tie a mailing list to
either an IAddress or an IUser.  For the latter, the user must have a
preferred address.

Each of these three data types can be associated with a preferences record,
and there is a defined order of lookup for any particular preference.  From
most highest priority to lowest it goes: member, address, user, system
default.

So how can a user have different settings for each subscribed list, even if
they are subscribed to all of them using their preferred address (i.e. through
the IUser record)?  Each subscription is represented by a unique IMember
record, and each one of those can have their own preferences.

User settings come into play in a number of situations.  For example, in the
"member-recipients' handler, where we calculate who is going to receive a
mailing list message, we'll look at their setting for 'receive_own_postings'.
If that's false, we won't add that user to the list of recipients.  Similarly,
this handler will look at whether their delivery status is enabled and whether
they are receiving "regular" (i.e. not digest) deliveries.

User settings may also come into play in the final delivery stage.  If the
mailing list is set up to do personalization (and/or VERP), then when we're
sending the personalized copy, we can pull information out of the user or
member record, such as their name and address for full personalization, or
other information for custom footers.

>What, if any, individual settings apply to moderator feeds? Are these
>different from those which apply to the feed that the individual receives as
>a member of the list?

Yes, because the other thing that an IMember associates with the subscription
is the role of the subscription.  So if you are both a member of the mailing
list (you get list postings) and a moderator, then there are two IMember
records linking your address/user to the mailing list, but they would have
different roles, and each IMember could have different preferences.
Moderator/owner delivery doesn't go through the same set of handlers as
regular delivery so not everything would honor different preferences.  For
example, you can't get digest delivery of owner messages.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130618/e07da7a3/attachment.pgp>

From barry at list.org  Wed Jun 19 00:54:04 2013
From: barry at list.org (Barry Warsaw)
Date: Tue, 18 Jun 2013 18:54:04 -0400
Subject: [Mailman-Developers] GSOC Project Discussion
In-Reply-To: <87txljbnjv.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAPkTf0Ktr+omV-Os72UGZqqG0AP3t3HuUHwX6fqwE=M+LkVOWg@mail.gmail.com>
	<87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CAPkTf0JTo0DKrYPz0qcHACkjpKUW3J32x=qZgbJouhO=iG-ZLQ@mail.gmail.com>
	<20130517161648.5691c17e@anarchist>
	<32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net>
	<20130530190721.014cf538@anarchist>
	<87txljbnjv.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20130618185404.6a651a51@anarchist>

On May 31, 2013, at 04:45 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > Here's where it gets interesting.  Rosters are not modeled as rows
> > in a table, they are modeled as queries. [...]
> > 
> > One of the use cases for rosters that I've always had in mind are a
> > better way to do MM2-style umbrella lists.  Let's say you have one
> > mailing list for all of your band's New York fans, and another for
> > all of your band's San Francisco fans.  It should be very easy to
> > compose a parent (i.e. umbrella) list which had a roster combining
> > the New York and San Francisco rosters,
>
>Meta: It would be nice if you would distinguish between the meanings
>of "should" in this kind of discussion.  Do you mean
>
>   1. One requirement for a good admin interface it to make it easy to
>   compose umbrella lists.
>
>or
>
>   2. This architecture is expected to make it easy for an admin
>   interface to compose umbrella lists.
>
>or both?

#2 mostly.  I'd rather not call them umbrella lists in Mailman 3, because I
think they'll operate differently and better-ly than in MM2.  The current
architecture allows for easy composability, although there isn't much support
for this in the current code base.  I.e. it would mostly be hand-coding right
now, but I think the hooks are there.

As to #1 - it would be nice!  But probably not a requirement.  :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130618/7d706dec/attachment.pgp>

From truongvunghia at gmail.com  Tue Jun 25 03:07:02 2013
From: truongvunghia at gmail.com (Nghia Vu Truong)
Date: Tue, 25 Jun 2013 02:07:02 +0100
Subject: [Mailman-Developers] Mailman structure
Message-ID: <51C8ED36.40101@gmail.com>

Hi everyone,
I am currently doing a project of expanding Mailman features.
However, I am a newbie, so I want to understand the structure of Mailman 
coding files.
Could any one know about this please help me, or please let me know 
which documents related to this problem!
Thanks so much
Nghia Truong

From barry at list.org  Tue Jun 25 15:42:29 2013
From: barry at list.org (Barry Warsaw)
Date: Tue, 25 Jun 2013 09:42:29 -0400
Subject: [Mailman-Developers] Auth/auth for Django
Message-ID: <20130625094229.79bdd1b5@anarchist>

I just saw this come across python-announce.  Would this at all be helpful for
Postorius or Hyperkitty?

http://peterhudec.github.io/authomatic/index.html
http://peterhudec.github.io/authomatic/examples/django-simple.html

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130625/e2b7b62e/attachment.pgp>

From barry at list.org  Tue Jun 25 16:52:48 2013
From: barry at list.org (Barry Warsaw)
Date: Tue, 25 Jun 2013 10:52:48 -0400
Subject: [Mailman-Developers] Mailman structure
In-Reply-To: <51C8ED36.40101@gmail.com>
References: <51C8ED36.40101@gmail.com>
Message-ID: <20130625105248.216c7c9d@anarchist>

Hi Nghia,

On Jun 25, 2013, at 02:07 AM, Nghia Vu Truong wrote:

>Hi everyone, I am currently doing a project of expanding Mailman features.
>However, I am a newbie, so I want to understand the structure of Mailman
>coding files.  Could any one know about this please help me, or please let me
>know which documents related to this problem!

When you say "structure of Mailman coding files", so you mean the file system
layout, the naming conventions, how the pieces fit together, or... ?

Also, are you asking about Mailman 2.1 or Mailman 3?

-Barry

From dkg at fifthhorseman.net  Thu Jun 27 20:11:40 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 27 Jun 2013 14:11:40 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC
	OpenPGP	Integration
In-Reply-To: <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <87li5ve84j.fsf@alice.fifthhorseman.net>

On Sat 2013-06-15 12:48:34 -0400, Stephen J. Turnbull wrote:

> Abhilash Raj writes:
>
>  > * 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.

I think Abhilash's question above is a really important question, and
one that really should be addressed by this GSoC project.  I'm not
claiming that the implementation needs to be perfect, but i do think
mailman should support something more sophisticated than "oh, anyone can
just upload a new key via the webinterface".

>  > * 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".

I like this latter proposal, and it should be pretty straightforward to
implement.  This means, of course, that the list-owner's key needs to be
known to the mailman instance.  could there be more than one
list-owner's key?

If someone wants to propose a more sophisticated key verification step
later, that could be an extension.

The above proposal makes the following things possible:

 0) mailman can fetch keys directly from the OpenPGP keyserver network
    if they haven't been uploaded directly, and still retain a
    reliable cryptographic chain (since any fetched keys that are not
    signed by the list-owner should be ignored).

 1) mailman can refresh keys automatically from the OpenPGP keyserver
    network, or accept arbitrary uploades of updated keys, also without
    worrying about non-cryptorgraphic compromise.  This means that
    people can update their key's expiration dates, and they can publish
    key revocation to the public keyserver network without needing to
    worry about fiddling with their subscription on every mailing list
    directly.

These are great!

It does raise a few logistical questions:

 A) if refreshing keys from the keyserver network is something we want
    mailman to do, when should it happen?  how often?

 B) if mailman can't find a valid key+userid for a known subscriber,
    when should it query the public keyservers to try to find one?

 C) how should mailman accept uploads of key material that *don't* go
    through the keyservers?

 D) if mailman notices that a subscriber's key has expired or been
    revoked or somehow become invalid in some other way, is it expected
    to notify that subscriber of the change in status?  if so, how? (i
    recommend that the answer is "no notification", at least in this
    initial implementation.

Thanks for weighing these options!

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130627/a4b83aee/attachment.pgp>

From stephen at xemacs.org  Fri Jun 28 06:03:42 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 28 Jun 2013 13:03:42 +0900
Subject: [Mailman-Developers] A list of discussion topics:
	GSoC	OpenPGP	Integration
In-Reply-To: <87li5ve84j.fsf@alice.fifthhorseman.net>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<87li5ve84j.fsf@alice.fifthhorseman.net>
Message-ID: <87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>

Daniel Kahn Gillmor writes:

 > I think Abhilash's question above is a really important question,

It is.

 > and one that really should be addressed by this GSoC project.

Vetoed (I'm the mentor).  Abhilash is welcome to work on key
management if he wants to, but he will not be evaluated on it (subject
to satisying the need discussed below for a simple, generic mechanism
to allow the list owner to conveniently authorize keys without
uploading them himself), and he will be warned if it appears that
mission creep is endangering the mission.

He is also welcome to use any free time he finds to work on encrypted
lists, and there's been mention of a conceptually similar project on
DMARC implementation (a message-signing technology for use by MTA
owners rather than list owners and members) that he may want to work on.
Which, if any, to do is up to Abhilash.  You're welcome to continue to
lobby him to work on key management though (in public, please :-).

But let's drop the discussion of a relation to GSoC, please.  Abhilash
has his contract, and key management policy is not in it.

 > I'm not claiming that the implementation needs to be perfect, but i
 > do think mailman should support something more sophisticated than
 > "oh, anyone can just upload a new key via the webinterface".

Nobody is saying otherwise.  I'm just saying that key management in
general is not Abhilash's problem for GSoC.  There does need to be a
way for list owners to take complete control of key management, and
there does need to be convenience in management.  I think that the
"key signed by list-owner's list-key-management-key" is an important
step for convenience.  I suspect that the hook needed to implement it
would be able to support various policies (probably through the 'chain
of rules' mechanism implemented in Mailman 3 core -- might require
some refactoring of core I guess).

 > I like this latter proposal, and it should be pretty
 > straightforward to implement.  This means, of course, that the
 > list-owner's key needs to be known to the mailman instance.  could
 > there be more than one list-owner's key?

Yes.  As implied above, I envision there being a specific key used to
sign for permission to do X FVO X such as subscribe, post, get member
list, sign other people's keys (Web of Trust!), etc, so there could be
several keys in that sense.  For paranoid folks who regularly expire
their keys, I would expect that keys might overlap in time, so there
probably should be a list of keys for each function.  In some cases
one key will fit all, of course: "I only sign for people I trust to do
everything a signature gives authorization to do".

 >  A) if refreshing keys from the keyserver network is something we want
 >     mailman to do, when should it happen?  how often?

Good questions, both the implicit one (do we want?) and the explict
ones.  Beyond my technical knowledge at the moment, though.

 >  B) if mailman can't find a valid key+userid for a known subscriber,
 >     when should it query the public keyservers to try to find one?

Immediately, subject to the caveat that this would possibly be a
separate queue.

Oh, I suppose you mean "should Mailman automatically add a key
that the user may not really have intended to use?"  That's an
extremely complex question.  If "signed by list owner" is the only
criterion and it's necessary and sufficient, I'd go with "always".
Otherwise you have a complex policy, and I'd have to see the policy to
know when querying is appropriate.

 >  C) how should mailman accept uploads of key material that *don't* go
 >     through the keyservers?

Please expand.  A signed key is a signed key, or isn't it?

 >  D) if mailman notices that a subscriber's key has expired or been
 >     revoked or somehow become invalid in some other way, is it expected
 >     to notify that subscriber of the change in status?  if so, how? (i
 >     recommend that the answer is "no notification", at least in this
 >     initial implementation.

I would expect that "noticing" would happen during the process of
authenticating a request.  If key status *changes* (a key that was
never valid for the list should cause silent denial of the request to
reduce backscatter), then the user should be notified that key status
has changed *and* how that was determined.  Anything else is going to
leave the list owner in the dock.  Also, the key owner may wish to
prosecute somebody for misuse of her key, and should be informed of
the misuse.

Steve


From barry at list.org  Fri Jun 28 16:11:08 2013
From: barry at list.org (Barry Warsaw)
Date: Fri, 28 Jun 2013 10:11:08 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC	OpenPGP
 Integration
In-Reply-To: <87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<87li5ve84j.fsf@alice.fifthhorseman.net>
	<87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20130628101108.53ceb370@anarchist>

All great questions.  Let me just add this.

On Jun 28, 2013, at 01:03 PM, Stephen J. Turnbull wrote:

>There does need to be a way for list owners to take complete control of key
>management, and there does need to be convenience in management.  I think
>that the "key signed by list-owner's list-key-management-key" is an important
>step for convenience.  I suspect that the hook needed to implement it would
>be able to support various policies (probably through the 'chain of rules'
>mechanism implemented in Mailman 3 core -- might require some refactoring of
>core I guess).
>
> > I like this latter proposal, and it should be pretty
> > straightforward to implement.  This means, of course, that the
> > list-owner's key needs to be known to the mailman instance.  could
> > there be more than one list-owner's key?
>
>Yes.  As implied above, I envision there being a specific key used to
>sign for permission to do X FVO X such as subscribe, post, get member
>list, sign other people's keys (Web of Trust!), etc, so there could be
>several keys in that sense.  For paranoid folks who regularly expire
>their keys, I would expect that keys might overlap in time, so there
>probably should be a list of keys for each function.  In some cases
>one key will fit all, of course: "I only sign for people I trust to do
>everything a signature gives authorization to do".

Another complication is that keys will probably be attached to users, but
users have relationships with list across the entire Mailman installation.  So
if it were list owners that were responsible for key management, how does that
cross list boundaries?  What about lists on the same system but in different
domains?  Does the site admin have to delegate key management responsibilities
to list owners?  I can imagine some kind of attack involving a list owner who
approves a member's key for one list, and then using that to attack other
lists on the same system.  Tricky business.

-Barry

From dkg at fifthhorseman.net  Fri Jun 28 17:46:40 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 28 Jun 2013 11:46:40 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<87li5ve84j.fsf@alice.fifthhorseman.net>
	<87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <51CDAFE0.10700@fifthhorseman.net>

On 06/28/2013 12:03 AM, Stephen J. Turnbull wrote:
> Daniel Kahn Gillmor writes:
> 
>  > I think Abhilash's question above is a really important question,
> 
> It is.
> 
>  > and one that really should be addressed by this GSoC project.
> 
> Vetoed (I'm the mentor).  Abhilash is welcome to work on key
> management if he wants to, but he will not be evaluated on it (subject
> to satisying the need discussed below for a simple, generic mechanism
> to allow the list owner to conveniently authorize keys without
> uploading them himself), and he will be warned if it appears that
> mission creep is endangering the mission.

ok, of course you have priority here, but i don't think we're actually
disagreeing :)  The "simple, generic mechanism" you describe *is* key
manangement as far as i'm concerned, and i think it's an excellent step.
 I wouldn't want the list to do much more than this, actually; we don't
want to encourage the list admin to do a lot of fiddly, error-prone,
list-specific work; normal public OpenPGP certifications should be able
to cover that.

> You're welcome to continue to
> lobby him to work on key management though (in public, please :-).

:)

> Yes.  As implied above, I envision there being a specific key used to
> sign for permission to do X FVO X such as subscribe, post, get member
> list, sign other people's keys (Web of Trust!), etc, so there could be
> several keys in that sense.  For paranoid folks who regularly expire
> their keys, I would expect that keys might overlap in time, so there
> probably should be a list of keys for each function.  In some cases
> one key will fit all, of course: "I only sign for people I trust to do
> everything a signature gives authorization to do".

I think this is too fine-grained, actually -- OpenPGP certifications
should attest to people's identities; those identities should have
permissions in mailman the same way that
non-cryptographically-verifiable identities have permissions in mailman.

The semantics are simple and graspable if we say "for list X, rely on
OpenPGP certifications from the following keys to prove cryptographic
identity".

>  >  A) if refreshing keys from the keyserver network is something we want
>  >     mailman to do, when should it happen?  how often?
> 
> Good questions, both the implicit one (do we want?) and the explict
> ones.  Beyond my technical knowledge at the moment, though.

As someone who has worked on this sort of key management in other
contexts (e.g. monkeysphere), the simplest mechanism is a scheduled
cronjob update from the keyservers.

One step up (fancier) is to couple the cronjob (which is still necessary
to check for revocations) with a key expiry script, that knows when the
next key or certification will expire and check from the keyservers at
that point in time.

If the cronjob is frequent enough, i don't think the fancier approach
has a great cost/benefit analysis, so i would just start with the cronjob.

Consider also that a cronjob that just does "gpg --refresh" should be
sufficient to pull in revocations and modifications to expiration dates,
but it won't pull in new keys that might be valid.  I think that's fine
for starters, and the new keys can be handled by:

>  >  B) if mailman can't find a valid key+userid for a known subscriber,
>  >     when should it query the public keyservers to try to find one?
> 
> Immediately, subject to the caveat that this would possibly be a
> separate queue.
> 
> Oh, I suppose you mean "should Mailman automatically add a key
> that the user may not really have intended to use?"  That's an
> extremely complex question.  If "signed by list owner" is the only
> criterion and it's necessary and sufficient, I'd go with "always".
> Otherwise you have a complex policy, and I'd have to see the policy to
> know when querying is appropriate.

I also think "always" is a reasonable default policy, though some list
managers may want to be able to set it to "never" if they don't want
arbitrary messages sent to the list to be able to force the list
software to interact with the public keyservers directly.

>  >  C) how should mailman accept uploads of key material that *don't* go
>  >     through the keyservers?
> 
> Please expand.  A signed key is a signed key, or isn't it?

ok, there are two approaches i can see:

 0) no key upload happens manually; all keys and OpenPGP certifications
are fetched from the public keyservers.  If a user's key isn't in the
public keyservers, or the certification by the list admin hasn't been
uploaded to the public keyservers are ignored.

 1) in addition to the use of the public keyservers, direct key upload
is allowed -- e.g. people can e-mail OpenPGP certificates to a special
address, or can upload them to a web form.  In this case, a user who
doesn't want their key on the public keyservers (or an admin who doesn't
want to distribute their certifications to the public keyservers) can
participate; also, a mailman installation which is (for whatever reason)
unable to access any of the public keyservers can still access it.

>  >  D) if mailman notices that a subscriber's key has expired or been
>  >     revoked or somehow become invalid in some other way, is it expected
>  >     to notify that subscriber of the change in status?  if so, how? (i
>  >     recommend that the answer is "no notification", at least in this
>  >     initial implementation.
> 
> I would expect that "noticing" would happen during the process of
> authenticating a request.  If key status *changes* (a key that was
> never valid for the list should cause silent denial of the request to
> reduce backscatter), then the user should be notified that key status
> has changed *and* how that was determined.  Anything else is going to
> leave the list owner in the dock.  Also, the key owner may wish to
> prosecute somebody for misuse of her key, and should be informed of
> the misuse.

i can see how this would be useful, but it means that there is more
fiddly tracking of the validity state of each (key,userid) pairing that
needs to be done to make this possible.  I suspect that the most common
change from valid to not-valid will be an expired key or an expired
certification (e.g. if the list owner's certification of the key
expires).  for the latter case, i can imagine that the certifier (the
list admin) might want to be notified as well.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130628/2d65d9b4/attachment.pgp>

From dkg at fifthhorseman.net  Fri Jun 28 17:48:01 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 28 Jun 2013 11:48:01 -0400
Subject: [Mailman-Developers] A list of discussion topics: GSoC	OpenPGP
 Integration
In-Reply-To: <20130628101108.53ceb370@anarchist>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<87li5ve84j.fsf@alice.fifthhorseman.net>
	<87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20130628101108.53ceb370@anarchist>
Message-ID: <51CDB031.8000205@fifthhorseman.net>

On 06/28/2013 10:11 AM, Barry Warsaw wrote:

> Another complication is that keys will probably be attached to users, but
> users have relationships with list across the entire Mailman installation.  So
> if it were list owners that were responsible for key management, how does that
> cross list boundaries?  What about lists on the same system but in different
> domains?  Does the site admin have to delegate key management responsibilities
> to list owners?  I can imagine some kind of attack involving a list owner who
> approves a member's key for one list, and then using that to attack other
> lists on the same system.  Tricky business.

An OpenPGP certification of a key+userid just means that the certifier
believes that the key belongs to the person who has that user ID
(including the e-mail address). i think the best way to implement
stephen's suggestion is that in order to be able to post to a
signed-message-only list, a list member must have a key that has been
certified by the list's administrator.

Note that this does *not* mean that a non-list-member whose key has been
certified by the list's administrator can post. List membership and key
certification are orthogonal attributes; Both should be needed (plus a
valid signature on the message, of course!) before a message is passed
on to such a list.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130628/21716764/attachment.pgp>

From stephen at xemacs.org  Sat Jun 29 06:49:26 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 29 Jun 2013 13:49:26 +0900
Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP
 Integration
In-Reply-To: <51CDAFE0.10700@fifthhorseman.net>
References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in>
	<87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<87li5ve84j.fsf@alice.fifthhorseman.net>
	<87ppv6yj8h.fsf@uwakimon.sk.tsukuba.ac.jp>
	<51CDAFE0.10700@fifthhorseman.net>
Message-ID: <87haghy10p.fsf@uwakimon.sk.tsukuba.ac.jp>

Daniel Kahn Gillmor writes:

 > ok, of course you have priority here, but i don't think we're actually
 > disagreeing :)

Good!

 > The "simple, generic mechanism" you describe *is* key
 > manangement as far as i'm concerned, and i think it's an excellent
 > step.

OK.  I remember the context as being one of actually implementing
(automated) policy decisions.  That's where I really don't want him to
go until the more limited GSoC project is done.

 > OpenPGP certifications should attest to people's identities; those
 > identities should have permissions in mailman the same way that
 > non-cryptographically-verifiable identities have permissions in
 > mailman.
 > 
 > The semantics are simple and graspable if we say "for list X, rely on
 > OpenPGP certifications from the following keys to prove cryptographic
 > identity".

So you're suggesting that the *only* policies that should be
automatically implementable via certified key are

(0) let this guy upload this key (and implicitly create a User if
    needed), but he can't do *anything* else (not even subscribe)
    until the list owner explicitly adds authorizations,

(0.5) this guy gets the intersection of sets of privileges I ever want
    to grant to anybody, and

(1) this guy is co-owner of this list

?

 > i can see how this would be useful, but it means that there is more
 > fiddly tracking of the validity state of each (key,userid) pairing
 > that needs to be done to make this possible.

I agree it's fiddly, I agree it's not in scope for Abhilash's GSoC
project, but for Mark's[1] sake I think we need to notify users whose
status changes from valid to invalid of the reason for the change.

 > I suspect that the most common change from valid to not-valid will
 > be an expired key or an expired certification (e.g. if the list
 > owner's certification of the key expires).  for the latter case, i
 > can imagine that the certifier (the list admin) might want to be
 > notified as well.

I would interpret a certification expiry differently: as the period of
time for which permission to register the key is valid.  If we want an
expiry for User authentication, probably a generic tool for managing
that in Mailman itself would be sufficient for this purpose and useful
elsewhere.


Footnotes: 
[1]  He's the guy who does the most work on fielding problem reports
from users.


From follybeachris at gmail.com  Sun Jun 30 04:12:42 2013
From: follybeachris at gmail.com (Chris Cargile)
Date: Sat, 29 Jun 2013 22:12:42 -0400
Subject: [Mailman-Developers] Mailman search function (was?? Re: Like to
 participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the
 list (Django, Python))
Message-ID: <CAHxCx-sEkzhhtLDiBQowwPNPOAKRs37cN6dqu5Sy0dpDwzaKBg@mail.gmail.com>

I have observed the mailman development activities for a while but have not
chimed in recently.

My initial aim for contributing was to offer input as to the search
functionality feature request.

In as much as there is a lot to gain from the continual flow of ideas that
I feel are spawned by my watching and considering the list posts, I find at
times it is a little arduous of a task to get the fine details I seek on
specific matters such as the search features' progress (this is intended to
be as much as compliment as anything, I suppose) ...or that I am grateful
for a chance to suggest my technique to tackle this 'burden' of organizing.

Whereas, certain resources may lead one to dismissively settle on allowing
google site-crawlers to work, this technique doesn't work (I'm glad) for
many, and I'm not sure where things stand regarding search for mailman-
however, I found Ian
Hicks<http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/>'
approach (of applying the HT-Dig capabilities to enhance a MM v2.0 instance
interesting, but perhaps overkill and/or not quite right) but a good
case-in-point for ideas.

I resolved my need for making 'search' on my lists practically achievable
but in terms of overall integration into the fabric of mailman code, it is
insufficient.

If you want to see my search implementation, check out a prototype from me
on my AWS instance<http://ec2-54-224-162-128.compute-1.amazonaws.com/pipermail/mailman/>
.

Please share your thoughts here or directly to me ;)

From follybeachris at gmail.com  Sun Jun 30 04:33:25 2013
From: follybeachris at gmail.com (Chris Cargile)
Date: Sat, 29 Jun 2013 22:33:25 -0400
Subject: [Mailman-Developers] Mailman search function (was?? Re: Like to
 participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the
 list (Django, Python))
In-Reply-To: <CAHxCx-sEkzhhtLDiBQowwPNPOAKRs37cN6dqu5Sy0dpDwzaKBg@mail.gmail.com>
References: <CAHxCx-sEkzhhtLDiBQowwPNPOAKRs37cN6dqu5Sy0dpDwzaKBg@mail.gmail.com>
Message-ID: <CAHxCx-vW97k5ohie0sXR0jENPV_tV8cp7YiUDYSYiAi0SVCxTQ@mail.gmail.com>

FWIW, I'd also like very much if anyone could provide a few lines recap of
the activity on the ModernArchiving topic under "initiatives and proposals"
as I feel my thoughts on searching/archiving tie into the
objectives/requirements listed there:
http://wiki.list.org/display/DEV/ModernArchiving

More concisely, where I have search capability, my goal of integrating more
'robustly' is I think one that will rely upon a channel of communication
being established with the archiving mechanisms, if I understand the mm 2.0
codebase well enough.

It may have been a while since anyone here has spent much time in the
version mm 2.0 code, but would love to start discussing/working with anyone
who's taking that on in v3.0..anyone?


On Sat, Jun 29, 2013 at 10:12 PM, Chris Cargile <follybeachris at gmail.com>wrote:

> I have observed the mailman development activities for a while but have not
> chimed in recently.
>
> My initial aim for contributing was to offer input as to the search
> functionality feature request.
>
> In as much as there is a lot to gain from the continual flow of ideas that
> I feel are spawned by my watching and considering the list posts, I find at
> times it is a little arduous of a task to get the fine details I seek on
> specific matters such as the search features' progress (this is intended to
> be as much as compliment as anything, I suppose) ...or that I am grateful
> for a chance to suggest my technique to tackle this 'burden' of organizing.
>
> Whereas, certain resources may lead one to dismissively settle on allowing
> google site-crawlers to work, this technique doesn't work (I'm glad) for
> many, and I'm not sure where things stand regarding search for mailman-
> however, I found Ian
> Hicks<http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/>'
> approach (of applying the HT-Dig capabilities to enhance a MM v2.0 instance
> interesting, but perhaps overkill and/or not quite right) but a good
> case-in-point for ideas.
>
> I resolved my need for making 'search' on my lists practically achievable
> but in terms of overall integration into the fabric of mailman code, it is
> insufficient.
>
> If you want to see my search implementation, check out a prototype from me
> on my AWS instance<
> http://ec2-54-224-162-128.compute-1.amazonaws.com/pipermail/mailman/>
> .
>
> Please share your thoughts here or directly to me ;)
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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/follybeachris%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From mark at msapiro.net  Sun Jun 30 04:47:42 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 29 Jun 2013 19:47:42 -0700
Subject: [Mailman-Developers] Mailman search function (was?? Re: Like to
 participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the
 list (Django, Python))
In-Reply-To: <CAHxCx-sEkzhhtLDiBQowwPNPOAKRs37cN6dqu5Sy0dpDwzaKBg@mail.gmail.com>
References: <CAHxCx-sEkzhhtLDiBQowwPNPOAKRs37cN6dqu5Sy0dpDwzaKBg@mail.gmail.com>
Message-ID: <51CF9C4E.8080202@msapiro.net>

On 06/29/2013 07:12 PM, Chris Cargile wrote:

> I'm not sure where things stand regarding search for mailman-
> however, I found Ian
> Hicks<http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/>'
> approach (of applying the HT-Dig capabilities to enhance a MM v2.0 instance
> interesting, but perhaps overkill and/or not quite right) but a good
> case-in-point for ideas.


It appears the archive at the above URL employs the indexing and htdig
patches for Mailman 2,1 originally developed by Richard Barrett
<http://www.openinfo.co.uk/mm/index.html> and now maintained by me
<http://www.msapiro.net/mm/>.


> I resolved my need for making 'search' on my lists practically achievable
> but in terms of overall integration into the fabric of mailman code, it is
> insufficient.


What more do you want?


> If you want to see my search implementation, check out a prototype from me
> on my AWS instance<http://ec2-54-224-162-128.compute-1.amazonaws.com/pipermail/mailman/>
> .
> 
> Please share your thoughts here or directly to me ;)


Your prototype looks fine, but what's behind /cgi-bin/search.py ?

Don't look for anything to be released for MM 2.1. The patches for htdig
are available and other methods are referenced in the FAQ. If anything
were to be released, it would be the htdig patches because that's what I
use, but it's problematic because of the htdig dependency.

For Mailman 3 the intent is that archivers will be "plugable", and the
defaults will be <http://www.mail-archive.com> and
<https://fedorahosted.org/hyperkitty/>

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Sun Jun 30 04:49:17 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 29 Jun 2013 19:49:17 -0700
Subject: [Mailman-Developers] Mailman search function (was?? Re: Like to
 participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the
 list (Django, Python))
In-Reply-To: <CAHxCx-vW97k5ohie0sXR0jENPV_tV8cp7YiUDYSYiAi0SVCxTQ@mail.gmail.com>
References: <CAHxCx-sEkzhhtLDiBQowwPNPOAKRs37cN6dqu5Sy0dpDwzaKBg@mail.gmail.com>
	<CAHxCx-vW97k5ohie0sXR0jENPV_tV8cp7YiUDYSYiAi0SVCxTQ@mail.gmail.com>
Message-ID: <51CF9CAD.3040509@msapiro.net>

On 06/29/2013 07:33 PM, Chris Cargile wrote:
> FWIW, I'd also like very much if anyone could provide a few lines recap of
> the activity on the ModernArchiving topic under "initiatives and proposals"
> as I feel my thoughts on searching/archiving tie into the
> objectives/requirements listed there:
> http://wiki.list.org/display/DEV/ModernArchiving


See <https://fedorahosted.org/hyperkitty/>

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan