Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-25 Thread Pierre Labrecque
Hello,

Wow !!! Thanks for your time !!!

Installation went well that time. I didn't see errors during the patch and 
update.php.
I notice some errors in Apache error.log:

Sun Aug 25 11:21:06 2013] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.7 
with Suhosin-Patch configured -- resuming normal operations

[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice:  
Undefined variable: cluster in 
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on 
line 282, referer: 
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACLaction=quickaccess

[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning:  Invalid 
argument supplied for foreach() in 
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on 
line 282, referer: 
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACLaction=quickaccess

[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice:  
Undefined index:  in 
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on 
line 341, referer: 
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACLaction=quickaccess

[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning:  Invalid 
argument supplied for foreach() in 
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on 
line 341, referer: 
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACLaction=quickaccess

[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice:  
Undefined variable: edges in 
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on 
line 357, referer: 
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACLaction=quickaccess

[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning:  Invalid 
argument supplied for foreach() in 
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on 
line 357, referer: 
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACLaction=quickaccess


Also: I went to Special:IntraACL and understand that I will have to learn how 
it works :-)
Is there a kind of user guide somewhere ? (in English, if possible :-), else 
I will try with Google Translate if in Russian...)
I believe that http://wiki.4intra.net/IntraACL/ru is the user guide ???

Also: not sure, but I believe to have read somewhere that IntraACL isn't 
compatible with Semantic ? True ? False ?

Thanks again !

Pierre

-Original Message-
From: mediawiki-enterprise-boun...@lists.wikimedia.org 
[mailto:mediawiki-enterprise-boun...@lists.wikimedia.org] On Behalf Of 
vita...@yourcmc.ru
Sent: Sunday, August 25, 2013 10:52 AM
To: MediaWiki for enterprises
Subject: Re: [Mediawiki-enterprise] How do you manage the security in your 
Mediawiki installation (Enterprise wiki) ?

 [Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice:
 Only variable references should be returned by reference in 
 /var/www/sites/mediawiki001/includes/Title.php on line 343, referer:
 
 http://servername/sites/mediawiki001/index.php?title=Special:UserLogin

Fixed, I didn't notice makeTitle is still function makeTitle(...). 
Is  still needed here? (question to Mark or someone else)

 [Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice:
 Undefined variable: titleObj in
 /var/www/sites/mediawiki001/includes/specials/SpecialUserlogin.php on 
 line 1004, referer: http:// servername 
 /sites/mediawiki001/index.php?title=Special:UserLogin

This one came from a previous patch (1.20.3). Fixed in master for both patches 
(1.20.3 and 1.21.1).

 [Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice:
 Only variable references should be returned by reference in 
 /var/www/sites/mediawiki001/includes/Title.php on line 343, referer:
 http:// servername
 /sites/mediawiki001/index.php?title=Special:UserLogin

Same as first.

 [Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Parse
 error:  syntax error, unexpected T_OBJECT_OPERATOR in
 
 /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ParserFu
 nctions.php on line 1365, referer: http:// servername 
 /sites/mediawiki001/index.php?title=Special:UserLogin

This one was an incompatibility with PHP 5.3 (it worked with 5.4+). 
Fixed.

 FYI:
 Ubuntu 12.04.2 Server (x64)
 Apache/2.2.22 (Ubuntu)
 PHP Version 5.3.10-1ubuntu3.7
 MySQL 5.5.29-0ubuntu0.12.04.1 x86_64
 Mediawiki 1.21.1

 Cheers !

Please try the master version again :)


___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-25 Thread vitalif

I can't T_OBJECT_OPERATOR anywhere in the code for IntrACL.  Where do
you see it in the code?


I've already fixed it, it was

(new Article($to))-doDeleteArticle(wfMsg('hacl_move_acl'));

PHP 5.3 does not allow to call a method on an expression.

___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-25 Thread Evgeniy Dankovcev
Hi Vitaliy,

Do you have any plans to add support of Semantic Mediawiki into IntraACL? 
We tried to use HaloACL on our wikis, but there are too many bugs and problems 
on large amount of articles

--
Evgeniy Dankovcev

On Aug 25, 2013, at 11:24, vita...@yourcmc.ru wrote:
 
 Also: not sure, but I believe to have read somewhere that IntraACL
 isn't compatible with Semantic ? True ? False ?
 
 Yes, it is, in the sense of that it doesn't protect SMW properties and query 
 results. It's mentioned on http://wiki.4intra.net/IntraACL/ru mostly because 
 the original extension (HaloACL) tried to protect them in some weird manner 
 (they've tried to encrypt them and then decrypt in some places O_o)... And 
 because I've removed this feature.
 
 It's basically incompatible with any extension that does direct database 
 access - i.e. its usage may lead to leaks. But it's usually simple to make it 
 compatible by just adding userCanRead() checks. Extensions that we use are 
 already patched, you can take them from github.
 
 ___
 Mediawiki-enterprise mailing list
 Mediawiki-enterprise@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise

___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-25 Thread vitalif

Hi Vitaliy,

Do you have any plans to add support of Semantic Mediawiki into 
IntraACL?

We tried to use HaloACL on our wikis, but there are too many bugs and
problems on large amount of articles


Hi, what support do you really want? I.e. do you want to protect 
properties like in HaloACL? (I've almost forgotten how it was done 
there... can you refresh it to me?)


Or normal page (subject) protection will be enough? The latter is in my 
plans, though for SMW it's slightly harder than for small extensions, 
and also by SMW people generally mean more semantic extensions... and 
they also need that support.


You can even do this patching job by yourself - it's simple, you just 
need to find places where the content is taken from / saved to the DB 
and add $title-userCanRead() checks there.


___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-25 Thread vitalif

Well. I don't know too ! :-) I didn't find it and opened all files
from the extension...


:) T_OBJECT_OPERATOR token is - for PHP. Didn't you see 
T_PAAMAYIM_NEKUDOTAYIM yet? :) that is hebrew for :: :)



2- I restart Apache (I thinks it's better as maybe LocalSettings.php
is in the cache...?): service apache2 restart


No, it's usually not cached. But of course an extra restart won't hurt 
:)



___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-24 Thread vitalif

Hi Pierre! I understand your dilemma perfectly well.
So, do we have to conclude that Mediawiki isn't a good choice for an 
enterprise (with these requierements) ???

Essencialy, yeah, MediaWiki sucks for the situations where you have
sensitive data stored on your pages and possible attackers.


And no money for paid wikis (Confluence and cie).


Well that's weird. You've described that the wiki will be used in 
such

a big scale... it seems to be pretty important project to spend
several thousand bucks (=salary of 1-3 employees for month) on it and
buy the TWiki or Confluence license.

For MediaWiki I can recommend IntraACL as well, but you have to be
sure that there is no potential attackers in your case.


Just to note, we have a setup consisting of several wikis as well; and 
we have automatic replication set up between them (through import/export 
and configs/maintenance/replicate.php script); and in each separate wiki 
there are many projects which sometimes have (and sometimes don't have) 
different access rights.


But 100+ different customers isn't our case... so it's simpler for us. 
An idea is to use a namespace for each customer for the isolation :) it 
would be very simple for users and I think the isolation would be strict 
enough with IntraACL. The problem would be the File namespace, but 
there's NSFileRepo extension... it allows to use more than one namespace 
for files. But of course it should be checked first.


Also, about the dilemma - I would still recommend MediaWiki, and it's 
not the performance on big databases which matters, but the 
extensibility.


___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-24 Thread vitalif
Oops sorry Pierre, the namespaces were your original idea. :) I was 
answering too fast (before I've read your previous messages) :)


___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-24 Thread Richard Heigl
Hi Pierre,

Your questions are crucial for enterprises but not easy to answer.

You can split up the content for different departments by using namespaces and 
lockdown. We have done this many times for customers and it works very well. 
The problem is sometimes the user interface, because the employees normally 
aren't familiar with the namespace concept, especially if they try to create a 
new page. We (in BlueSpice) give some support via the page template system. 
There you can say I have a new page for Department A and the template creates 
the new page in the new namespace. That's possible way, but that all can be 
improved :)

And there is sometimes trouble, because the uploaded media are all in the same 
namespace.

But mostly we find solutions, because images, office-documents are already in 
the file system or in a DMS or in SharePoint and we build a connector or offer 
the possibility to use file links. If your customers think twice, he often 
realizes, that he doesn't want all documents with all duplicates in the wiki 
and in the search results. The reading rights for these documents are mostly 
managed by the Active Directory or LDAP server. So there is no security problem 
for documents at all.
But to have a small DMS in MediaWiki would be helpful or - better - plugins 
for nice open source systems like agorum. And what is about WebDAV?

For large companies, especially for transnational ones we recommend several 
wikis for different languages, departments or content types. I know Confluence 
and all the others promises all-in-one-solutions. That's sounds great for the 
CIO but for the usability it isn't. Several wikis are better for orientation 
(what is this wiki for ...), for searching in (results only in your 
language...) and regarding access control issues. Four or five wikis should be 
centrally organized in a wiki farm.

And, maybe an interesting alternative, we have realized a wiki switch for a 
supermarket corporation. So you can switch between a public wiki for partners 
and an internal wiki for staff members.

Best regards,
Richard



Dr. Richard Heigl
Strategieberatung

Hallo Welt! - Medienwerkstatt GmbH
__

Residenzstraße 2
93047 Regensburg

Tel.  +49 (0) 941 - 66 0 80-193
Fax   +49 (0) 941 - 66 0 80-189

www.hallowelt.biz
he...@hallowelt.biz


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani


Von: mediawiki-enterprise-boun...@lists.wikimedia.org 
[mailto:mediawiki-enterprise-boun...@lists.wikimedia.org] Im Auftrag von Pierre 
Labrecque
Gesendet: Freitag, 23. August 2013 23:36
An: 'MediaWiki for enterprises'
Betreff: [Mediawiki-enterprise] How do you manage the security in your 
Mediawiki installation (Enterprise wiki) ?

Hello,

We continue to do our homeworks concerning a project we have to build a wiki 
for our enterprise: 80 000 employees, but only 1000 of them could have access 
to the wiki: usually in read, some people in read/write. We will need per 
namespace security: some namespaces should not be read by some groups... We 
don't want to go with many tons of wikis installation...

I wrote a post on another mailing list about it a couple of days ago: 
http://www.gossamer-threads.com/lists/wiki/mediawiki/381274
I had some very good and helpful comments, but it's after that I found another 
mailing list (this one), which seems dedicated to the enterprise usage of 
Mediaiwki.

Here are the requierement we have:

Main page

-NamespaceA (read for departmentA only)

-NamespaceB (read for departmentB only)

-

-NamespaceZ (read for departmentZ)
Sometimes, someone of departmentA will need read access to NamespaceZ, etc...

I would like to have some testimonials: your experiences, your 
recommendations... on a specific aspect of Mediawiki: ACL !!! (recurring topic, 
I believe...).

I read 
http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-question-of-features/
 and found that they use Lockdown and some other extensions around it, to 
secure the wiki
As everyone, I read 
http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions and 
http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions
So, I wrote to BlueSpice team to know if they believe that Lockdown is really 
secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as 
expected).

I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms 
that Mediawiki is the wrong tool to manage that kind of ACL and that they use 
other tools for sensitive data, not their wiki... I didn't insist to know which 
other tool... I was impressed that a guy at this level take the time to answer 
me, so... :)

Anyway, could you tell me what is the kind of setup you have on this side (ACL) 
? Certainly that some of you use in the facts an ACL extension (Lockdown

Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-24 Thread vitalif

First of all: thank you for all your comments and efforts ! I really
appreciate all of them ! When I see all this, I take confidence in 
the

human being... You have all my respect.

Seems that we may have a potential solution (?) :-)

I know that we can't close all doors... it is perhaps not prevent all
risks, but to learn how to manage the limit (can we say that in
english ???)

I downloaded IntraACL from the storage-rewrite git branch to do a 
test.

Under patches/ there is no IntraACL-MediaWiki-*.diff for our
Mediawiki version: 1.21.1
Anyway, I have done a backup of our dev virtual machine and then try
to to apply IntraACL-MediaWiki-1.20.3.diff to our 1.21.1 installation
(just to try and guess): of course I got some errors on lines ...

Question: is there a IntraACL-MediaWiki-xxx.diff for 1.21.1 somewhere
? Else, do you suggest to install 1.20.3 (or 1.20.6) instead of the
latest MV version ? (because there is an available diff for 
1.20.3...)


Again: thanks you all 


I'm sure storage-rewrite still has bugs, so I think you should better 
take master by now. Rewritten version will be totally compatible with 
current one (the update will be as easy as just running 
maintenance/update.php).


I've updated the patch for 1.21.1 - it's not so hard, but I didn't test 
the result yet :-)) you can pull from master and try it out :)



___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-24 Thread Pierre Labrecque
FYI:
I commented line 178 of extensions/IntraACL/includes/HACL_GlobalFunctions.php

I modified LocalSettings.php (add the next 2 lines):

require_once($IP/extensions/IntraACL/includes/HACL_Initialize.php);
enableIntraACL();

Then:
cd /var/www/sites/mediawiki001
patch -p1 extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff

When I press ENTER after the patch command, nothing append... it stay there 
forever...
Just a cursor that doesn't blink, nothing...

??


-Original Message-
From: Mark A. Hershberger [mailto:m...@nichework.com] 
Sent: Saturday, August 24, 2013 1:23 PM
To: MediaWiki for enterprises
Cc: Pierre Labrecque
Subject: Re: [Mediawiki-enterprise] How do you manage the security in your 
Mediawiki installation (Enterprise wiki) ?

On 08/24/2013 12:51 PM, Pierre Labrecque wrote:
 PHP Fatal error:  Call to undefined function wfLoadExtensionMessages()

Comment out line 178 of
extensions/IntraACL/includes/HACL_GlobalFunctions.php and it should work.

I'll submit a patch for the extension.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-24 Thread Mark A. Hershberger
On 08/24/2013 03:22 PM, Pierre Labrecque wrote:
 cd /var/www/sites/mediawiki001
 patch -p1 extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
 
 When I press ENTER after the patch command, nothing append... it stay there 
 forever...
 Just a cursor that doesn't blink, nothing...

You are missing a character:

  patch -p1  extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff

You see the blinking cursor and nothing else because patch is stupid and
doesn't see that you've given it the patch file on the command line.  It
expects to read it from STDIN and that is what the  does.

-- 
http://hexmode.com/

Love alone reveals the true shape of the universe.
 -- Everywhere Present, Stephen Freeman

___
Mediawiki-enterprise mailing list
Mediawiki-enterprise@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise


Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?

2013-08-23 Thread Pierre Labrecque
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise 
(with these requierements) ??? I can't say to our management: hey ! pay for a 
developer to patch Lockdown and the core...and in a couple of months/years, the 
hole system may fail after an upgrade of MW... (caricature). :-)

The context: 
1- many customers: for each customers, we have many teams to support them. Each 
of these teams needs a secure space for its documents.
2- of course, all these teams (dedicated to different customers) share some 
general documents. We don't need or want to secure everything: a lot of stuff 
can be shared by everyone.

Here is the design we try to explore actually: 
1- create a shared wiki (in our office)
2- create a single wiki, on the network of a customer (so if 100 customers, it 
means 100 wikis: one per customer, each one on the customer network)

As it doesn't make sense for us that an employee of customer X visits the 
shared wiki to have access to general documents, then visits its own wiki (on 
the customer network) to access restricted stuff, we though to put in place a 
system where the admin of the customer wiki access the shared wiki and pulls 
some interesting info from the shared to the customer wiki. It has its 
limits... just a possibility...

So let's say it's a good idea... it means that the customer wiki will be 
accessible by all our employees dedicated to this customer... but in this wiki, 
there are many documents too, that we need to secure too.
So:

1- Shared Wiki: (accessible by all admin of customer wikis, these admin pull 
info from it to put general stuff in their own wiki)
2- Customers Wikis (accessible by our people, located on the customers 
facilities)
3- Customers Wikis: accessible by each of our employees, dedicated to this 
customers. So if Jack and Daniel work for CompanyA, it means that both will log 
into the CompanyA wiki.
4- Customers Wikis: Jack and Daniel have different roles. Jack is a computer 
technician and must have access to general software procedures. Daniel works 
with servers and is specialized in the firewall configuration of this 
customer... Jack should not see the stuff of Daniel, right ? We believe that 
this info is sensitive... So it means that we need to secure some namespace 
(for example) to prevent Jack to access Daniel stuff... So LockDown extension ?
5- Security: here, if MW with Lockdown fails, it will be a failure which will 
stay on the customer network (damage is limited, but absolutely not 
desirable!!!). That's one of the reason we prefer to separate general stuff 
(shared wiki) from the customer wiki (sensitive): isolation of the failure. If 
we put Lockdown on a single wiki, shared by all, and that a failure occurs: it 
means that every customer may be able to access the data of everyone else 
(firewall config for example...).

That's where we are for now...
Yes: Dokuwiki, MoinMoin, etc... have ACL and are cerftainly the best choice for 
medium size wikis. But what's append with these wiki engines when you have 
200/300/400 000 - 1 000 000 pages ? Are they seriously designed to support all 
these pages/images/doc, etc ? The search feature will become slow ? etc... we 
don't know...
And no money for paid wikis (Confluence and cie).

What else: there are a tons of wiki engines. Why we prefer to have Mediawiki ? 
Well... to be honest... it's Mediawiki :-)

I sincerely hope that my English is clear... :-)

Cheers !

-Original Message-
From: mediawiki-enterprise-boun...@lists.wikimedia.org 
[mailto:mediawiki-enterprise-boun...@lists.wikimedia.org] On Behalf Of Yury 
Katkov
Sent: Friday, August 23, 2013 6:32 PM
To: MediaWiki for enterprises
Subject: Re: [Mediawiki-enterprise] How do you manage the security in your 
Mediawiki installation (Enterprise wiki) ?

I guess that one option for you will be to hire somebody or some company for 
developing Lockdown further so that they can cover all the holes from which the 
information can bet got. HalloWelt itself is a perfect candidate and we also 
have a lot more developers available [1]. Probably you will also want to hire 
different contractor that will try to steal the data from the modified 
extension.

Of course, after some time the extension will stop working because of ugly 
hacks that will definetely appear in the code.

Another and more proper solution is not so fast, that is: to lobby the proper 
ACL support in MediaWiki core before starting development.
MediaWiki is used as an enterprise wiki and the impossibility of good ACL 
should not be considered as not some kind of philosophy of the software (as 
some people claims) but as a bug that needs fixing. Still even in this case the 
actual development of ACL won't be done by WMF - they aren't just interested in 
it. But if we would have carte blanche for patching the core and not been 
declined because MW is an Open System, it has not been Designed to allow ACL 
support, I think many parties will be interested