[Openvpn-devel] Ubuntu Repository
Hi, Just curious - any plans to update the repository (at http://swupdate.openvpn.net/apt), now that Ubuntu 16.04 LTS is out? Thanks! ... Russell
Re: [Openvpn-devel] SPAM on trac
Wow. Previously nothing of this magnitude has been encountered. Luckily this crap is, afaik, invisible to normal users, because the pages are linked to from anywhere (except the TitleIndex). Based on the history of the spam pages the spammer(s) used many user accounts, and the edits were spread over a period of over 32 hours at least. Assuming bots have not found a way around the Google reCAPTCHA we use in the registration webapp these are real human spammers. Anyways, I'll turn on a bunch of other spam filtering services in Trac today, then add a few more on Monday. I'll also get rid of this crap after more spam filtering is in place. I hope we can avoid the situation where all edits have to be made by known-good people. Right now Wiki edits are disabled for everyone except a select few. Hi, I turned on several new external content scanning spamfilters. In the process I had to upgrade Trac and the Trac spam filtering plugin. We used to only have Akismet, because we didn't really have any big spam issues. Now we have all of these activated: - Akismet (http://akismet.com/) - Blogspam (http://blogspam.net/) - StopForumSpam (http://stopforumspam.com/) - BotScout (http://botscout.com/) - Fspamlist (http://www.fspamlist.com/) Based on spam monitoring and Trac logs the filters seem to work, but we'd need actual spam attempts to prove that[*]. Right now the "karma" setup on Trac is such that if one service thinks the content is spam then the edit will be rejected. I also reduced the maximum number of edits per IP to 5 per hour, and activated Google reCAPTCHA. I did not see reCAPTCHAs, though, when doing ticket test edits, so it might only apply to anonymous edits; in that case it would be useless for us. There are a few other spam detection services which we can probably activate later: - Spamwipe (http://spamwipe.com/): registration does not work atm - Mollom (http://mollom.com/) I also did a mass removal of the spam Wiki pages (500+). The bastards had contaminated some of our useful Wiki pages, but deducing which ones was fairly easy given direct access to the database. I believe I managed to delete all the contaminated revisions. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [*] I did not want my own IP to get added to various IP blacklists, so I did not try "spamming" myself.
Re: [Openvpn-devel] SPAM on trac
Wow. Previously nothing of this magnitude has been encountered. Luckily this crap is, afaik, invisible to normal users, because the pages are linked to from anywhere (except the TitleIndex). Based on the history of the spam pages the spammer(s) used many user accounts, and the edits were spread over a period of over 32 hours at least. Assuming bots have not found a way around the Google reCAPTCHA we use in the registration webapp these are real human spammers. Anyways, I'll turn on a bunch of other spam filtering services in Trac today, then add a few more on Monday. I'll also get rid of this crap after more spam filtering is in place. I hope we can avoid the situation where all edits have to be made by known-good people. Right now Wiki edits are disabled for everyone except a select few. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock We have a spammer :( https://community.openvpn.net/openvpn/wiki/TitleIndex Lots of it .. Regards -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] SPAM on trac
I think I’ve cleaned everything up. Users will need to ask for permission to update the wiki. Eric > On Apr 29, 2016, at 13:51:07, debbie10twrote: > > The lamest spam I ever did see :D > > Is this a complaint ? > http://postimg.org/image/fre81b9zl/ > > this guy knows about spam filters > today has been a torrent of spam .. > (No more on this list .. time to resume development) > > > > > -- > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Openvpn-devel] Artificial delays during connection setup
On 29/04/16 21:19, Jiri Horky wrote: > Thanks for the quick response. > > On 04/29/2016 07:08 PM, Arne Schwabe wrote: >> Am 29.04.16 um 19:51 schrieb Jiri Horky: >>> Hi list, >>> >>> I was wondering why the connection setup on Linux with openvpn 2.3.10 >>> takes about 2.5s even on local network and dig deeper in the code. It >>> seems there are two places where an artificial delay of 1s is added. >>> >>> First one is waiting before checking the connection status is checked in >>> src/openvpn/init.c >>> >>> 1108 if (!deferred) >>> 1109 { >>> 1110 /* initialize connection establishment timer */ >>> event_timeout_init (>c2.wait_for_connect, 1, now); >>> 1112 >> I think nobody knows anymore why there is this timeout and without >> proper testing/codereview just removing it might be a bit dangerous. > At least on Linux, I checked that the client was doing completely > nothing during this wait (no syscall, nor other activity). On > Windows/Android, we need to check more. It will also be needed to verify this from a server perspective as well. I see that do_init_timers() are also called via do_deferred_options() via multi_connection_established() via multi_process_post() - from a very quick 30 seconds look at the code looks to be used on both client and server. -- kind regards, David Sommerseth