Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <4FACFCBB.2030609@wandisco.com>
Date: Fri, 11 May 2012 12:49:15 +0100
From: Gary <gary.martin@wandisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: Suspicious ticket raised
References: <062.58ee4cdc394d4ecf46ae50fc1b17f186@incubator.apache.org>
 <4FA39A30.5050307@wandisco.com>
 <CABD8fLVW3CCF5mxG=c7W-KmKE9RycX1yNvDRNLwKoY59-PvewA@mail.gmail.com>
In-Reply-To: 
 <CABD8fLVW3CCF5mxG=c7W-KmKE9RycX1yNvDRNLwKoY59-PvewA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 05/11/2012 09:48 AM, Greg Stein wrote:
> On Fri, May 4, 2012 at 4:58 AM, Gary<gary.martin@wandisco.com>  wrote:
>> Hi
>>
>> Sorry to seem so suspicious but I guess everyone would be surprised if this
>> turned out to be a genuine ticket. I am going to assume that it is
>> malicious. Unless anyone can provide me with a good reason to do otherwise,
>> I will close the account and find a way of dealing with the ticket. Until
>> then I suggest that nobody visits the link in the ticket.
>>
>> I realise that this is, so far, an isolated case at this point but we should
>> probably consider an appropriate procedure for dealing with these
>> situations, unless there is already a policy given by the ASF.
> There's no special policy. This was obviously spam... you're right in
> just closing the thing. "Closing as invalid."
>
> (theoretically, somebody trying to open a valid ticket would re-open)
>
> Cheers,
> -g

Good to know, thanks.

We got a couple of spam events this morning too, this time in the wiki. 
To deal with this, I have temporarily reduced the permissions for the 
general authenticated group of users and added all accounts to an 
additional group that provides the edit and create permissions.

I am not advocating at this point that this should become our default 
policy and, unless this is actually seen as a better policy, I expect to 
return edit and create permissions to all authenticated users in the 
near future. One consequence of leaving the permissions in this state is 
that a new registration will also need to ask for the edit permissions 
to be added to their account.

Cheers,
     Gary