[Mailman-Developers] Really: architecting extra profile info [was: About authentication...]
Terri Oda writes: > Oh! I think I understand some of the confusion now. I thought I'd > said at the beginning why I was starting this thread at all, which > is primarily because Systers has a student project that needs extra > profile info. That was a long time ago, and ... none of the students actually applying to Mailman has expressed direct interest in the extra profile info. To the contrary, a couple have commented that crypto really interests them. stylistica posted here and has been on IRC off and on, but hasn't applied through Mailman. dardie will need a profile API, I think, but *her* proposal just showed up in the last hour or so and is an early draft. > The problem is ... somebody who knows the requirements needs to explain them on *Mailman* channels. We (more precisely, you, 'cause I don't know who to ask) need to get the principals in here, or in a conversation off-list. Then we'll work it out. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Using Mailman scripts from cgi
Tom Browder writes: > I've tried: > $ ./add_member -r - listname j...@test.org > > and > > $ ./add_member -r - listname < j...@test.org > > but neither works. I just get the command's help output. > > I am in the bin dir with the script and I'm a member of the list group. echo j...@test.org | ./add_member -r - mailman works for me. (Tip: If I don't have a test list handy, I use the mailman list.) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
> On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter wrote: > > I believe you have been asked very politely not to continue this > > thread yesterday and give way for more pressing topics such as > > GSoC. Can you please do so? This is in rather bad taste. Richard and I have been actively involved in mentoring the GSoC students, and we care about them. Please respect that, at least to the extent of reading the messages we write about the project. Richard Wackerbarth writes: > I consider that [a priori ruling out submitted proposals] is > totally inappropriate. I won't go so far as to say "totally" inappropriate. We do have to get some work done, and if the consensus is that strict adherence to the letter of Terri's post is the best way to move along ... I'll deal with it. I hope we can find a compromise, though. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
Terri, For Systers, is it better to try to access Postorius through its REST API or by directly including it as a django app? In particular, using Django 1.5 and the custom user module feature that it provides along with the scheme that I outlined earlier provides an easy path to developing and integrating features such as the essays into the user profile. Basically, we share a common User model. Someone can start by using the standard django.contrib model and ignore the Postorius specific parts. I am willing to implement the pieces (I estimate needing only a day or two if I do a simple version), but I also think that it would be an appropriate task for one of the students. Richard On Apr 30, 2013, at 10:31 AM, Terri Oda wrote: > On 13-04-29 11:28 PM, Stephen J. Turnbull wrote: >> Actually, there aren't any students explicitly discussing extra profile >> information in their proposals. They talk airily about "extended REST >> API" or similarly generic terms. None talk about storage or >> representation of profile information. (OK, it was 3am, my memory is >> fallible. I don't remember any, though.) >> > > Oh! I think I understand some of the confusion now. I thought I'd said at > the beginning why I was starting this thread at all, which is primarily > because Systers has a student project that needs extra profile info. There > are also a collection of students with minor features that would use the data > store that they've used to pad out projects that might otherwise be too short > (For example, see some of the ideas Peter Markou mentioned in his recent > post). But now that you mention it, I've been talking to a lot of folk on > IRC and they often don't tell me if they're applying with Mailman or Systers, > so maybe there's more of them with Systers than with Mailman? > > > For those not familiar, Systers runs a heavily modified version of Mailman > 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman > Suite (whenever that's going to be), but they've got a few features that > they'll need to either have integrated to core Mailman or maintained as > branches. This year, they've got a project set up to port one of them to > Mailman 3/Postorius as part of preparing them for that. > > The specific feature they're hoping to add this year stores essays that > people write when they subscribe. It's currently done with a database > grafted on to Mailman 2.1 that was being used for another extended feature, > but obviously if we're going to mentor such a project for Mailman 3, we'd > like to use something at least approximating a real data store design. The > problem is that the Systers mentors are mostly used to systers-mailman, based > on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide > a student through a halfway reasonable design, so I asked here in order to > help them out so that their student could start on the essays (likely to be > the easier part of her project) right at the beginning of the GSoC period. > If we can't come to a moderate consensus on that design, I should be telling > the Systers folk that this project won't be able to run this year, but I > honestly figured we'd have a simple design after a couple of posts... I > wasn't counting on aut hentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project. > > So yeah, totally cool to be thinking about the more advanced projects in > general, but I started this thread due to a specific need for a "good enough > approximation for this Mailman suite release" version of the extra data > store, and I still need a consensus on that that's either implemented or > simple enough for a student to do in the first week of GSoC. I think we're > pretty close to that point, but I'm not sure it's yet described in a way that > we can hand it off safely to a student and get a REST API that actually > meaningfully matches the discussion within a couple of days. Probably we > need an actual set of doctests for the student to work against next and then > we'll be there. > > Incidentally, I've been trying to get the students interested in this > particular Systers project to come to this mailing list and join in the > discussion, but it's become *very* intimidating to take part in this thread, > which is the other reason I need folk to take a step back. > > Terri > > ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
On 13-04-29 11:28 PM, Stephen J. Turnbull wrote: Actually, there aren't any students explicitly discussing extra profile information in their proposals. They talk airily about "extended REST API" or similarly generic terms. None talk about storage or representation of profile information. (OK, it was 3am, my memory is fallible. I don't remember any, though.) Oh! I think I understand some of the confusion now. I thought I'd said at the beginning why I was starting this thread at all, which is primarily because Systers has a student project that needs extra profile info. There are also a collection of students with minor features that would use the data store that they've used to pad out projects that might otherwise be too short (For example, see some of the ideas Peter Markou mentioned in his recent post). But now that you mention it, I've been talking to a lot of folk on IRC and they often don't tell me if they're applying with Mailman or Systers, so maybe there's more of them with Systers than with Mailman? For those not familiar, Systers runs a heavily modified version of Mailman 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman Suite (whenever that's going to be), but they've got a few features that they'll need to either have integrated to core Mailman or maintained as branches. This year, they've got a project set up to port one of them to Mailman 3/Postorius as part of preparing them for that. The specific feature they're hoping to add this year stores essays that people write when they subscribe. It's currently done with a database grafted on to Mailman 2.1 that was being used for another extended feature, but obviously if we're going to mentor such a project for Mailman 3, we'd like to use something at least approximating a real data store design. The problem is that the Systers mentors are mostly used to systers-mailman, based on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide a student through a halfway reasonable design, so I asked here in order to help them out so that their student could start on the essays (likely to be the easier part of her project) right at the beginning of the GSoC period. If we can't come to a moderate consensus on that design, I should be telling the Systers folk that this project won't be able to run this year, but I honestly figured we'd have a simple design after a couple of posts... I wasn't counting on authentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project. So yeah, totally cool to be thinking about the more advanced projects in general, but I started this thread due to a specific need for a "good enough approximation for this Mailman suite release" version of the extra data store, and I still need a consensus on that that's either implemented or simple enough for a student to do in the first week of GSoC. I think we're pretty close to that point, but I'm not sure it's yet described in a way that we can hand it off safely to a student and get a REST API that actually meaningfully matches the discussion within a couple of days. Probably we need an actual set of doctests for the student to work against next and then we'll be there. Incidentally, I've been trying to get the students interested in this particular Systers project to come to this mailing list and join in the discussion, but it's become *very* intimidating to take part in this thread, which is the other reason I need folk to take a step back. Terri ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
Richard Wackerbarth writes: > In my opinion, the normal use case doesn't even need the generality > of "domains". I'm not going to argue with you. Let's go get some code written. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Using Mailman scripts from cgi
I'm probably going in the wrong direction, but I'm trying to create my own page for subscribers on an Ubuntu server. Before I get my cgi form working, I'm trying to use the command line script "add_members" and can't get the right syntax for using stdin. I've tried: $ ./add_member -r - listname j...@test.org and $ ./add_member -r - listname < j...@test.org but neither works. I just get the command's help output. I am in the bin dir with the script and I'm a member of the list group. What am I doing wrong? Thanks, -Tom ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
Patrick, This IS about GSoC. If we accept Terri's position, as stated and without question, then we are, de facto, eliminating some of the proposals based only on subject matter. The students making these proposals are doing so in good faith, and often based on "ideas" provided by our organization. I consider that doing so is totally inappropriate. As I state, we need to maintain a structure whereby each of the proposed projects can proceed without being blocked by another project, but done in such a manner that they can be integrated into the whole as they develop into functioning code. Richard On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter wrote: > Richard, > > * Richard Wackerbarth : >> Again, we agree. (Something must be wrong :) ) I think that it is important >> that "we" (the senior developers and mentors) assure that we maintain a >> structure whereby each of the student proposals can proceed at the same time. > > I believe you have been asked very politely not to continue this thread > yesterday and give way for more pressing topics such as GSoC. Can you please > do so? > > p@rick > > -- > [*] sys4 AG > > http://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstraße 15, 81669 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > > ___ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
Richard, * Richard Wackerbarth : > Again, we agree. (Something must be wrong :) ) I think that it is important > that "we" (the senior developers and mentors) assure that we maintain a > structure whereby each of the student proposals can proceed at the same time. I believe you have been asked very politely not to continue this thread yesterday and give way for more pressing topics such as GSoC. Can you please do so? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
Steve, Again, we agree. (Something must be wrong :) ) I think that it is important that "we" (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time. Thus, for example, someone working on the User interface can do so without requiring the "secure" mail features. At the same time, we provide a place (Eg. the Credentials store) that can be used to hold public keys associated with individual subscribers. Now I will admit that I haven't thought about the criteria associated with permitting someone to add a public key-->user association. But, within whatever policy is needed, we have a method to handle the storage and the framework within which the system can "GetUserByCredential()", etc. Richard On Apr 30, 2013, at 12:28 AM, Stephen J. Turnbull wrote: > Terri Oda writes: > >> 1. I would like to remind/tell you all that FOR THIS RELEASE, we will >> ONLY be supporting Mozilla Persona and passwords as authentication >> methods. > >> 3. While I agree that thinking about these things in advance is useful, >> I think this discussion is starting to crowd out discussions of >> time-sensitive things like students' GSoC applications and >> architectural choices that directly impact how they write said >> applications. > > Hold on! Who's "we" and what is being released? There are at least 3 > more or less separate projects here (Mailman core, Postorius, and > HyperKitty). For login of the webapps Postorius and HyperKitty, I > certainly agree that aiming releasing them simultaneously with core > 3.0, focusing on a particular authn mechanism (and given work done at > the sprints, it should be Persona) is appropriate. > > But Mailman 3.0 is *not* the only item on the agenda here. We have a > pile of GSoC students who want to implement various forms of authn for > Mailman core functionality (secure lists) and some REST API (not clear > to me which subproject these adhere to, the core Mailman REST API or a > new one to be provided by Postorius). AFAICT, *Persona is not > appropriate* for these use cases, as it implies interactive use of a > full-featured web browser. > > Are you saying that (despite our ideas page) these proposals are a > priori nearly unacceptable? It's also rather late in the process to > change the rules on the students: if experience is any guide, Melange > availability is going to start deteriorating soon. > >> So... can we please backburner parts of this discussion until after >> GSoC so that we don't make it impossible for anyone to start on any >> project involving extra profile info? I don't want to bog down a >> student with the need to make this choice and work with these >> decisions at this stage. > > Actually, there aren't any students explicitly discussing extra profile > information in their proposals. They talk airily about "extended REST > API" or similarly generic terms. None talk about storage or > representation of profile information. (OK, it was 3am, my memory is > fallible. I don't remember any, though.) > > >> For the purposes of GSoC this summer: >> >> Authentication for the purposes of the extra profile info data store >> will be provided by either Persona through the web interface or >> passwords. > > OK. > >> Yes, even internally for the REST interface: passwords+localhost >> are good enough for Mailman Core right now, so it's good enough for >> anything else we do short-term. > > That's going to strongly bias decision-making against at least one > REST API proposal, which was made in good faith. > > It also formally seems to rule out the secure lists proposal, which > obviously depends on an off-line non-localhost authn protocol (based > on OpenPGP or S/MIME). Is that your intention? > > Regards, ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
Steve, In my opinion, the normal use case doesn't even need the generality of "domains". Now that we are talking about only the few percent remaining installations, I have to seriously ask how many of those will not be handled by "power users"? My concern is that, in your effort to "protect" the less sophisticated, you are excluding some very few, but extremely "powerful" users. I share the goal of "world domination". I don't want to exclude anyone if we can avoid it. Richard On Apr 29, 2013, at 11:57 PM, Stephen J. Turnbull wrote: > Richard Wackerbarth writes: > >> There are two aspects of using a "generic tree". The first is some >> customization of the tree to fit the installation's delegation >> model. Here, I would suggest that "sample base installations" > > Once again, you're making an argument based on theory that nobody > disagrees with, certainly not me, and not even attempting to address > my request for use cases. > > We're not making progress. Let's just agree to disagree, and accept > that there's a rather high probability that we can't work together. > In commenting, I'll play the loyal opposition, and we can hope other > developers will keep me honest. > > Regards, > Steve > ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9