[Openvpn-devel] Ubuntu Repository

2016-04-30 Thread Morris, Russell
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

2016-04-30 Thread Samuli Seppänen



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

2016-04-30 Thread Samuli Seppänen
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

2016-04-30 Thread Eric Crist
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, debbie10t  wrote:
> 
> 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

2016-04-30 Thread David Sommerseth
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