Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

2016-02-17 Thread Elizabeth K. Joseph 
On Mon, Feb 15, 2016 at 7:46 AM, Jeremy Stanley  wrote:
> On 2016-02-15 09:04:41 -0600 (-0600), JP Maxwell wrote:
>> Tom, yes we can probably help. Do you want to ping me off list -
>> need to get some more info about how it is setup / version
>> controlled / deployed / etc.
>
> Our openstack_project::wiki class[1] calls into our mediawiki Puppet
> module[2]. Ryan Lane set up and maintained most of this for us while
> he was at WMF, but since he's moved on to other things it's fallen
> into some disuse so assistance is appreciated!
>
> [1] 
> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/wiki.pp
> [2] http://git.openstack.org/cgit/openstack-infra/puppet-mediawiki/tree/

As Jeremy points out, our infrastructure is all open source so I'd
prefer to keep this discussion here on the list so we can all pitch
in. I don't see any active patches for this yet (please let me know if
I've missed anything).

Another data point: Canonical IS also uses Launchpad authentication,
like we do, for edits to their Ubuntu wikis and have been hit pretty
hard by spammers this week (initial attacks go back to December). They
are on MoinMoin, we're on Mediawiki, so wiki-side anti-spam proposals
will differ, but I've been keeping an eye on any solutions they may
propose for altering how SSO is being handled for their wiki to
perhaps shut these spammers down before they get a chance to edit.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

2016-02-17 Thread JP Maxwell 
Sure.. So a couple of thoughts:

1. If the attack vector involves creating a launchpad account, there's not
much we can do about that portion (account creation).   But, we could
potentially force the user to do a re-captcha when they want to edit /
insert content.   This doesn't fix the creation of fake accounts, but at
least enables a basic check of humanity before editing is allowed.

2. It was discovered that the mobile view does not invoke the SSO via
launchpad.  While it appears this is unrelated to the spam and should take
a lower priority, I would propose going ahead and fixing this for good
measure.

3. Longer term - using OpenStack ID instead of LaunchPad.  Would have to
either implement a sunset period as Martin suggested or have the user
authenticate to both SSO providers creating a relationship in the users
table of mediawiki.   The ability / complexity of such an approach would
need to be investigated.

Input is welcome.  I'll investigate whatever path people agree with and
welcome other suggestions.

J.P. Maxwell / tipit.net 


On Wed, Feb 17, 2016 at 2:21 PM, Elizabeth K. Joseph 
wrote:

> On Mon, Feb 15, 2016 at 7:46 AM, Jeremy Stanley  wrote:
> > On 2016-02-15 09:04:41 -0600 (-0600), JP Maxwell wrote:
> >> Tom, yes we can probably help. Do you want to ping me off list -
> >> need to get some more info about how it is setup / version
> >> controlled / deployed / etc.
> >
> > Our openstack_project::wiki class[1] calls into our mediawiki Puppet
> > module[2]. Ryan Lane set up and maintained most of this for us while
> > he was at WMF, but since he's moved on to other things it's fallen
> > into some disuse so assistance is appreciated!
> >
> > [1]
> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/wiki.pp
> > [2] http://git.openstack.org/cgit/openstack-infra/puppet-mediawiki/tree/
>
> As Jeremy points out, our infrastructure is all open source so I'd
> prefer to keep this discussion here on the list so we can all pitch
> in. I don't see any active patches for this yet (please let me know if
> I've missed anything).
>
> Another data point: Canonical IS also uses Launchpad authentication,
> like we do, for edits to their Ubuntu wikis and have been hit pretty
> hard by spammers this week (initial attacks go back to December). They
> are on MoinMoin, we're on Mediawiki, so wiki-side anti-spam proposals
> will differ, but I've been keeping an eye on any solutions they may
> propose for altering how SSO is being handled for their wiki to
> perhaps shut these spammers down before they get a chance to edit.
>
> --
> Elizabeth Krumbach Joseph || Lyz || pleia2
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB optional parameters usefulness

2016-02-17 Thread Thanh Ha 
On 16 February 2016 at 10:03, Darragh Bailey 
wrote:

> Think it all comes down to the following:
> * Need to understand what exactly is happening within Jenkins with
> regard to XML updating, clearly not just taking the XML given and
> changing to match that, more likely some kind of merge is going on.
>

Agreed. I'll try to reach out to the Jenkins team and see if I can get a
statement from them about how this is supposed to work.


> * Is the sort of workflow described by David limited to the disabled
> tag, or useful elsewhere? If limited I think we should handle
> 'disabled' as a special case.
>

Agreed. I think we should handle it specially and making sure it's
documented. I do see it being useful for "disabled". David can you confirm
if there's other fields you believe needs to be handled specially like this
one?


> * If the decision is to change behaviour going forward, initially
> needs to only apply to new settings being added and have a way of
> converting existing code while matching existing behaviour via some
> setting.
>
> Expect we'll have to support existing use of optionals for at least
> one major release for the current modules whether we decide to switch
> the behaviour for the future or not. So the change identified will
> have to keep that in consideration.
>

I'm not sure how much the impact is but unless you ever purposely set an
optional setting to something previously, the optional parameter in Jenkins
is the default setting already just not explicitly. I've only ever been hit
with this issue when I set something on purpose and decide later that I no
longer want it and delete the setting, expecting it to revert to the
default.

I'm not sure how best to handle this as it is a behaviour change and would
be difficult to support 2 behaviours at the same time as it's hard to tell
which one should be used. One thought is if we're going with the
discussions from patch https://review.openstack.org/261620/

1. Put a single warning when JJB completes running that states something
like:

ATTENTION: The behaviour of parameters marked as (optional) is
changing. In future releases if not passed they will revert to a default
setting.

2. We can add the "fail_required=False" parameter to the convert_mapping_to_xml
function as suggested

This leaves existing functionality for plugins that use the
convert_mapping_to_xml function at least to stay the same and for all new
plugins set "fail_required=True", after a few releases we can flip the
switch so that it's True by default.

3. We start converting plugins using convert_mapping_to_xml function with
the fail_required=True setting and set correct "defaults" for optional
settings

Kien is my intern for the upcoming summer intern program and I think would
be a good project for him to work on. I think this would be a good start,
and would quickly simplify the code we maintain for the various modules.

Thoughts?

Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

2016-02-17 Thread Elizabeth K. Joseph 
On Wed, Feb 17, 2016 at 1:19 PM, JP Maxwell  wrote:
> Sure.. So a couple of thoughts:
>
> 1. If the attack vector involves creating a launchpad account, there's not
> much we can do about that portion (account creation).   But, we could
> potentially force the user to do a re-captcha when they want to edit /
> insert content.   This doesn't fix the creation of fake accounts, but at
> least enables a basic check of humanity before editing is allowed.

Thanks for taking some time to look at this today! If we could find an
open source captcha option, that may be part of the solution.

Do you think you might have some time to also look at the other
generalized Mediawiki proposals that Clint Byrum linked to earlier in
the thread? I don't think we've really made the time to do an audit in
this direction and starting to implement some of them may help.

https://www.mediawiki.org/wiki/Manual:Combating_spam

> 2. It was discovered that the mobile view does not invoke the SSO via
> launchpad.  While it appears this is unrelated to the spam and should take a
> lower priority, I would propose going ahead and fixing this for good
> measure.

This is definitely a hole that should be plugged at some point.

> 3. Longer term - using OpenStack ID instead of LaunchPad.  Would have to
> either implement a sunset period as Martin suggested or have the user
> authenticate to both SSO providers creating a relationship in the users
> table of mediawiki.   The ability / complexity of such an approach would
> need to be investigated.

Longer term, definitely. We've been slowly working to move various
services over to OpenStackID and I think the wiki is a great
candidate. Tom kicked off a "Moving wiki.o.o to OpenStackID login?"
thread about it last Thursday and we've very gradually started looking
into the migration considerations, thread starts here:
http://lists.openstack.org/pipermail/openstack-infra/2016-February/thread.html#3787

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

2016-02-17 Thread JP Maxwell 
>
>
>
> Thanks for taking some time to look at this today! If we could find an
> open source captcha option, that may be part of the solution.
>
> Do you think you might have some time to also look at the other
> generalized Mediawiki proposals that Clint Byrum linked to earlier in
> the thread? I don't think we've really made the time to do an audit in
> this direction and starting to implement some of them may help.
>
> https://www.mediawiki.org/wiki/Manual:Combating_spam
>
>
Yes - the first item is "Requiring log in and/or a CAPTCHA on certain
operations, such as edits, adding external links, or new user creation."

There are a number of captcha extensions:

https://www.mediawiki.org/wiki/Extension:ConfirmEdit

is bundled with v1.18 and above which it looks like v.1.24 is what this
wiki is on judging by this meta tag:


So it may just be a matter of specifying what type of captcha is required
for edit operations.

I will install a local copy and have a closer look at this.  But, it seems
like a relatively easy and logical first step.  We can always ratchet
things up from there if it doesn't work.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra