From steve at einval.com Thu Oct 18 13:16:26 2018 From: steve at einval.com (Steve McIntyre) Date: Thu, 18 Oct 2018 18:16:26 +0100 Subject: [moin-devel] spam fighting ... In-Reply-To: <4ab5ec1f-2f4b-e60c-439b-0f924553bfee@waldmann-edv.de> References: <4ab5ec1f-2f4b-e60c-439b-0f924553bfee@waldmann-edv.de> Message-ID: <20181018171621.xzl47xvnyyfnxjnp@tack.einval.com> On Mon, Aug 20, 2018 at 03:30:50PM +0200, Thomas Waldmann wrote: >... 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. Cool. :-) >* 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. Well, too many idiots and too many bots. Not enough spammers have been set on fire. :-/ >For wikis without internet exposure, the more strict new default >settings can be undone via the wiki config, if desired. Nod. I'd still love you to take our patch to add email verification - I'd hope it would be useful for lots of people. -- Steve McIntyre, Cambridge, UK. steve at einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden From steve at einval.com Thu Oct 18 13:05:41 2018 From: steve at einval.com (Steve McIntyre) Date: Thu, 18 Oct 2018 18:05:41 +0100 Subject: [moin-devel] Current state of Debian efforts with Moin In-Reply-To: References: <20180819235954.wziijcjp5lt4dwyy@tack.einval.com> Message-ID: <20181018170535.dviodtp7kkzedw3r@tack.einval.com> Much belated response, sorry... :-( On Mon, Aug 20, 2018 at 02:54:37PM +0200, Thomas Waldmann wrote: > >> https://salsa.debian.org/debian/moin/tree/master/debian/patches > >Have gone through them (again) and the current state is like that: > >> fix_wrong_digestmod_of_hmac.new_calls.patch > >Patch from download page (I guess), fixed in git already. Yup, that's where we picked it up from. >> fix_rss.patch Fix rss_rc action to stop crashes > >I opened github issue, please add more details there: > >https://github.com/moinwiki/moin-1.9/issues/25 Sorry, responding here instead. I closed my github account when they were bought out by Microsoft. :-( On wiki.debian.org we saw lots of errors, as shown in https://bugs.debian.org/787583 looking like mod_wsgi (pid=1755): Exception occurred processing WSGI script '/srv/wiki.debian.org/bin/moin.wsgi'. Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/werkzeug/wsgi.py", line 588, in __call__ return self.app(environ, start_response) File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 264, in __call__ response = run(context) File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 89, in run response = dispatch(request, context, action_name) File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 137, in dispatch response = handle_action(context, pagename, action_name) File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 203, in handle_action handler(context.page.page_name, context) File "/usr/lib/python2.7/dist-packages/MoinMoin/action/rss_rc.py", line 178, in execute handler._write( AttributeError: RssGenerator instance has no attribute '_write' This simple patch made the noise stop. I'll admit we've not looked at this in a while... >> incremental-dump.patch implement an incremental dump process >> Implement an incremental dump process. >> This also fixes dumping of the attachments. >> This also allows the dump script to be interrupted. > >Sounds useful, but for 1.9.10 guess I'ld prefer a bug report about what >is broken with the attachments and a fix-only pull request that fixes >just that. > > >> disable_gui_editor_if_fckeditor_missing.patch >> hardcode_configdir.patch >> htdocs_moved_to_usr_share_moin.patch >> use_systemwide_libs.patch > >Dist packaging specific, not needed upstream. ACK. >> remove_favicon.patch > >Cosmetic. But it's something that affects privacy. We've got a policy of removing remote resources like favicons from Debian packages where possible. >> external_account_creation_check.patch >> mail-verification.patch >> netaddr_hosts_deny.patch >> recaptcha.patch > >Lots of efforts on spam fighting. > >We need to fight spam bots, but the problem is that (AFAIK) they have >already worked around all these mechanisms. They're part of a defence-in-depth approach for us. recaptcha is not all that useful for us now, but the others help: * We verify emails, so we have email addresses attached to accounts at least. * Next, we call out to an external script to validate account creation. That script uses a lot of heuristics to determine how spammy a new account signup attempt is, and has the power to blacklist IP addresses etc. We analyze the logs from that script to see what's going on and potentially block wider blocks of addresses. * The netaddr_hosts_deny patch is something I've just developed and we haven't yet deployed it. The existing code to simply match using startswith is very limited... >I'll write a separate mail about my recent attempts on spam fighting. ACK, saw that - I'll respond to that too. >> * A check of the licensing in Moin showed up two sets of images where >> licensing is not as clear as we'd like: > >Ugh. Well, I guess this is rather a documentation issue than a licensing >issue as IIRC we never have used anything we are not permitted to use. > >But I also can't remember the details about these 7 icons. Guess we have >them since > 10 years. Right. We're developing better and better QA tools in Debian - they picked up on these files which have been around for a very long time. Do you know where they came from, and who committed them? I've tried to contact the people involved from the embedded information, with no response. >(the list is longer than 7 because they were copied into multiple themes) Nod. > >> There's also a range of bug reports in the Debian BTS: >> >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=moin > >https://github.com/moinwiki/moin-1.9/issues/26 ACK. :-) -- Steve McIntyre, Cambridge, UK. steve at einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross