[Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Rajeev S]

>
> Please don't top-post.  It's very helpful to readers to keep the
> "subthreads" about particular issues separate, while at the same time
> bundling them together for ease of mail-handling.
>
> Why not?  The CLI tools will have access to the user database, so in
> theory you could authenticate.  In *practice*, this may be outside of
> the scope of your project because there's no provision for
> authentication in the current RESTful interface; you end up
> restricting to connections from localhost.
>

I have given this some thought and yes, you can authenticate and authorize
in both shell and tools interface. Authn/authz in shell is quite
straightforward as Abhilash mentioned and with the CLI tools, it can be
achieved, in a not so easy way. SSH keys can be used to register your shell
with the server which can be used as a token for authn/authz for the shell
user, just like the interface provided by cloud services like heroku.You do
a *heroku login *from your shell and you can run commands on the remote
server of your application from your shell.This would be an interesting
project and would hugely benefit usability of the current project.


> But by the same token, past projects have decided to connect to
> Postorius rather than Mailman itself precisely because Postorious
> *does* maintain roles and credentials for users.  Again, probably
> beyond the scope of your project, but for precisely this reason it has
> been proposed a few times that the authn/authz part of Postorius be
> broken out into a separate module.
>
> I agree with your logic here.
>
> But I find the text very difficult to read.  There should be at least
> one space after a sentence-ending period ("Yes.Users" looks like a
> class attribute!)  And I have no idea what the semantics of "*" is
> intended to be.



That seems like a funny GMail bug. All I did was to reorder the terms of
the phrase which was in boldface, using cut and paste. Anyway, I will
remember not to do this again.


> Despite the current thread on python-dev<wink target="Barry"/>, I
> strongly recommend the pep8.py tool (available on PyPI as well as
> upstream: https://github.com/jcrocholl/pep8/).  pyflakes, pylint, and
> pychecker are also good tools, but their orientation is a bit
> different, and you may or may not find them useful (and in particular
> you may find after a while that you *never* get warnings from them).
>
> I have used pychecker before. Barry's guide<http://barry.warsaw.us/software/STYLEGUIDE.txt> followed
by a PEP8 verifier would do good.