Mailman 3 August 2018 - moin-devel

spam fighting ...
by Thomas Waldmann Oct. 18, 2018

Oct. 18, 2018

... the never ending story. Here are some of my recent attempts in moin-1.9 github repo (soon in 1.9.10 release): * disabled the "newaccount" action by default. This is to avoid that for internet-exposed wikis spam bots can create lots of user accounts in little time. To avoid forcing the wiki admin to create accounts on the shell (or having to toggle the availability of the newaccount action temporarily), I slightly modified the superuser's "Switch user" capability (see "Settings" of superuser): It is now able to switch to a non-existing user (and just create a new user profile on the fly). So, as a superuser one only needs to give the new username, switch to it, fill in the user's email address and then the account can be claimed by the user on the login page via the "forgot password" functionality (then setting a password, modifying profile settings as needed). While this method imposes some work on someone in the superuser list, it is totally safe against spammers: there is no way humans or spam bots can create accounts without the help of a superuser. * safer internal default ACL: Known and All now only have read permissions. This is to avoid that you accidentally give r/w permissions to the world when running a wiki on the internet. I recently shot myself into the foot by forgetting to configure a safer default ACL (only used acl_rights_before, but did not lock out All/Known for writing). Sample configs: suggest to use an EditorGroup. Again, this is a bit more work for wiki admins / group members, but it is totally safe against spammers: - no default write permissions for All (anon users) - no default write permissions for Known (anyone who managed to create an account, see also newaccount action) - you can not create/modify pages without logging in AND being explicitly allowed by an ACL (by name or by group membership) Using e.g. an EditorGroup, the work needed to give some legitimate user write permissions can be distributed onto all members of some group (e.g. EditorGroup or AdminGroup). Note: not much in the original spirit of wiki (allow changes and revert them if they are bad), but guess there are too many idiots out there for this. For wikis without internet exposure, the more strict new default settings can be undone via the wiki config, if desired. -- GPG ID: 9F88FB52FAF7B393 GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393

2 1

Current state of Debian efforts with Moin
by Steve McIntyre Oct. 18, 2018

Oct. 18, 2018

Hey folks, As promised in irc a few days ago... We're still using 1.9.9 with a few local patches - see https://salsa.debian.org/debian/moin/tree/master/debian/patches for the full set. I've just added one new patch that's not yet released in Debian, adding support for proper netmasks when adding IP blocks - see netaddr_hosts_deny.patch. I've got two more issues that could do with fixes: * We have a large list of blocked addresses to deal with spam. We'd like to split that into two: + addresses allowed to read the wiki, but not make changes nor sign up for accounts + addresses totally blocked (the current behaviour) We have a lot of users complaining that they're blocked, particularly if they're using commercial VPN providers who can't/won't do anything about spammers. I'm hoping to work on this soon, but I've got a long TODO list on other Debian-related projects too. * A check of the licensing in Moin showed up two sets of images where licensing is not as clear as we'd like: MoinMoin/web/static/htdocs/classic/img/idea.png MoinMoin/web/static/htdocs/classic/img/redface.png MoinMoin/web/static/htdocs/classic/img/sad.png MoinMoin/web/static/htdocs/classic/img/smile.png MoinMoin/web/static/htdocs/classic/img/smile2.png MoinMoin/web/static/htdocs/classic/img/smile3.png MoinMoin/web/static/htdocs/modern/img/idea.png MoinMoin/web/static/htdocs/modern/img/redface.png MoinMoin/web/static/htdocs/modern/img/sad.png MoinMoin/web/static/htdocs/modern/img/smile.png MoinMoin/web/static/htdocs/modern/img/smile2.png MoinMoin/web/static/htdocs/modern/img/smile3.png MoinMoin/web/static/htdocs/rightsidebar/img/idea.png MoinMoin/web/static/htdocs/rightsidebar/img/redface.png MoinMoin/web/static/htdocs/rightsidebar/img/sad.png MoinMoin/web/static/htdocs/rightsidebar/img/smile.png MoinMoin/web/static/htdocs/rightsidebar/img/smile2.png MoinMoin/web/static/htdocs/rightsidebar/img/smile3.png These all contain text saying Copyright: 1999, Philipp Esselbach <ple(a)gmx.net> but there's no mention of him or a license grant anywhere I can find. MoinMoin/web/static/htdocs/classic/img/moin-new.png MoinMoin/web/static/htdocs/modern/img/moin-new.png MoinMoin/web/static/htdocs/rightsidebar/img/moin-new.png Thses all say: Copyright: 1996, Leo Doerr <http://www.silverpoint.com/> but there's no mention of him or a license grant anywhere I can find. There's also a range of bug reports in the Debian BTS: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=moin Most aren't too important IMHO, but others may find them interesting. -- Steve McIntyre, Cambridge, UK. steve(a)einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier ----- End forwarded message ----- -- Steve McIntyre, Cambridge, UK. steve(a)einval.com Into the distance, a ribbon of black Stretched to the point of no turning back

2 2

Re: [moin-devel] returning back and what are your plans?
by Steve McIntyre Aug. 19, 2018

Aug. 19, 2018

On Wed, Aug 15, 2018 at 06:24:01PM +0200, Paul Boddie wrote: >On Wednesday 15. August 2018 17.53.21 Reimar Bauer wrote: >> >> after a long break in actively developing moin-2 I am thinking about >> refactoring it to moin-3 (py3) and getting it in a state that we could >> migrate a bunch of our wikis. > >First of all, welcome back! > >I've never been able to get into doing anything with Moin 2. It seems like >there are so many dependencies, and I just don't buy into the Python-centric >way of handling dependencies. Moreover, delegating dependency management to >Python-only tools does little to help packaging for operating system >distributions. Oh, hmmm. :-/ That would be a problem for us in Debian maybe. >Apart from that, I think that the focus of many people has been to keep what >they already have working. Unfortunately, bugs have gone unfixed upstream. I >guess that Thomas isn't so interested in Moin any more, or is this a complete >misinterpretation? Having noted that the Debian people use and improve Moin >quite a bit, maybe they have something to say about this. We've been fairly quiet lately, but see my other mail. Almost all the patches we've added are to make Moin work better for us in terms of managing users and spam. There are more intrusive changes I've been thinking about for ages [1] but I've never got around to (and maybe never will). [1] https://bugs.debian.org/705114 ... >Well, I don't know if you've been following the list, but there hasn't been >too much traffic of late. I noted recently that for some of my sites, I don't >need an active Moin instance since I'm just using Moin to deploy content. To >avoid maintenance issues - log and cache files ballooning, worries about how >secure things are - I've been writing tools to deal with Moin-formatted >content plus accessories such as the Graphviz parser. I've got a few scripts locally too. I'm particularly looking at adding configurable "this page needs checking/updating every N months, please check it" style alerts. We have a huge corpus of pages, and lots of the content is painfully out of date... :-/ -- Steve McIntyre, Cambridge, UK. steve(a)einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead

1 0

MoinMoin 1.9.x development moved to GitHub
by Thomas Waldmann Aug. 17, 2018

Aug. 17, 2018

See there: https://github.com/moinwiki/moin-1.9/ Currently working on a 1.9.10 release, please check if something important is missing. If so, file an issue there. No big features for 1.9.x, just small / important stuff. Currently open issues: https://github.com/moinwiki/moin-1.9/issues If you contributed to MoinMoin < 2.0 in the past and you'ld like to have your commits associated with your github accounts, see issue #1.

1 0

returning back and what are your plans?
by Reimar Bauer Aug. 15, 2018

Aug. 15, 2018

Dear all, after a long break in actively developing moin-2 I am thinking about refactoring it to moin-3 (py3) and getting it in a state that we could migrate a bunch of our wikis. I think it is worse to do that refactoring with moin-1.9. We have a little more than one year and if we want to keep moinmoin alive - now a bit more pressure. ;) Goal is to get a wiki like system, addons done later. So what do you think? Who is in a similiar situation than me and wants to spend time? cheers Reimar

3 3

TextCha not working because of wrong signature
by Jasper Olbrich Aug. 11, 2018

Aug. 11, 2018

Hello, I configured TextCha some time ago because bots seem to have found my account creation page. Now I'm unable to create new users or edit pages, because the answer to the TextCha is always considered wrong. This is because the reconstruction of the question from the form data fails. It all seems to boil down to a wrong digest method: In security/textcha.py: ---------------------- [...] SHA1_LEN = 40 [...] def _compute_signature(self, question, timestamp): signature = u"%s%d" % (question, timestamp) return hmac.new(self.secret, signature.encode('utf 8')).hexdigest() ---------------------- But hmac.new uses md5 per default with a length of 32 hex digits: >>> import hashlib >>> import hmac >>> len(hmac.new("key", "msg").hexdigest()) 32 >>> len(hmac.new("key", "msg", hashlib.sha1).hexdigest()) 40 I couldn't find any information on this yet and I'm asking what the right fix to this would be? 1) Explicitly use hashlib.sha1? 2) Use an universal DIGEST_LEN=len(hmac.new("key", "").hexdigest())? 3) ??? And of course I'm curious why this hasn't bitten anybody else so far. -- Best, Jasper

2 2