Page MenuHomePhabricator

Deploy Extension:Lockdown to the cluster and enable on OTRS Wiki
Closed, DeclinedPublic

Description

To enhance security of confidential correspondences, enable https://www.mediawiki.org/wiki/Extension:Lockdown on the private OTRS wiki. Requested by the OTRS admins.

Event Timeline

Mdennis-WMF raised the priority of this task from to Needs Triage.
Mdennis-WMF updated the task description. (Show Details)
Mdennis-WMF added a project: acl*sre-team.
Mdennis-WMF added subscribers: Mdennis-WMF, Keegan.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 13 2015, 9:06 PM
pajz added a subscriber: pajz.Apr 13 2015, 9:07 PM
Legoktm set Security to None.
Legoktm added a subscriber: Legoktm.

Lockdown isn't installed on any WMF wiki, so it'll need a security review before deployment (also see https://www.mediawiki.org/wiki/Review_queue). Given the huge disclaimer at the top of the extension page, it seems unlikely that we'd actually deploy it...

What's the use case anyway?

What's the use case anyway?

I'm curious to know as well.

Platonides added a subscriber: Platonides.EditedApr 13 2015, 9:22 PM

I don't think the disclaimer is a stopper, provided that it is understood as a fallible solution by the people using it. However, like Krenair, I must also ask: what they are trying to achieve?
It seems unlikely that really confidential correspondences should be placed on otrswiki.

PS: Regarding to the extension security, when I looked at it some years ago, the extension was quite good, and indeed it's coded by Daniel Kinzler.

(not commenting on the usefulness yet just because I don't know the goals, but the disclaimer itself shouldn't be a blocker in any way. That's a standard disclaimer we put on the top of all page restriction extensions. "Not built for this" is a good warning to give, but given our culture if it's important then it is probably better then moving to a totally different piece of wiki software etc.

I think we can probably decline this as per T3924 without having to even get to the security issues involved.

pajz added a comment.Apr 13 2015, 9:48 PM

The use case is as follows: Per current policies, we restrict access to OTRS Wiki to a subset of agents (mostly so-called "volunteer accounts," i.e. volunteers who work on info, permissions etc. queues). OTRS Wiki, however, serves a dual purpose: On the one hand, it hosts all the documentation as well as the coordination pages (say, a page to request account changes from an administrator); on the other hand, it is also a place where volunteers discuss, say, complicated cases that come up in the info-en::copyright queue. This is also why access it restricted to volunteer accounts, with all other OTRS agents only getting an account as needed.

Understandably, many "non-volunteers" (in the above terminology; many are also volunteers, of course, but have access for other reasons than the described, e.g. to coordinate a Wikipedia-related event) complained that they would like to have access to the help and coordination pages on OTRS Wiki as well. And it's true: There's no argument for not giving them access to these pages. And for that reason it would be desirable to be able to give every OTRS agent an OTRS Wiki account, but have a particular namespace to which only our volunteer accounts have access. That way, every side's interest could be taken into account.

Jalexander added a comment.EditedApr 13 2015, 9:49 PM

I think we can probably decline this as per T3924 without having to even get to the security issues involved.

I would strongly recommend we not decline anything at this point. That ticket was about putting something into core, which this ticket does not seem to be asking for. If the OTRS admins (or even a portion of them) think something like this is needed the best move is to figure out the use case and the reasonings and if restrictions are even a useful response to that.

If it IS a something they end up needing I think there is something very different between finding an extension that will "get it done" even if we refuse to put it in core and don't support it. This is especially true for a project that supports us all, I think that would be better then the alternative of forcing our own information off of MediaWiki (which is what we generally tell people asking for this in core).

There are a lot of ways information can leak between namespaces, and I don't think Lockdown is going to prevent them all. Core should mostly respect the decisions it gets from Lockdown about access (although it's not something we check for regularly, since we don't use it on WMF sites-- so it's a little bit chicken and egg). We would also need to look carefully at how the extensions installed there handle different pieces to make sure they don't leak.

Lockdown has a set of features that our third-party users often want. I think it would be a great goal to make Lockdown safe, with Wikimedia resources behind it. I'm not sure we currently have the resources to correctly do it at the moment, I'll have a better idea next quarter.

In the meantime, it sounds like the functionality OTRS wiki is looking for can be done with a (large and constantly updating..) set of whitelisted pages?

Lockdown has a set of features that our third-party users often want. I think it would be a great goal to make Lockdown safe, with Wikimedia resources behind it. I'm not sure we currently have the resources to correctly do it at the moment, I'll have a better idea next quarter.
In the meantime, it sounds like the functionality OTRS wiki is looking for can be done with a (large and constantly updating..) set of whitelisted pages?

Patrick and other admins: Do you think this would be a good interim solution? (does it meet the goals for now?) Though a bit more cumbersome I and others can certainly help to keep the list up to date. I think the most important question is if the documentation pages would work still on otrs-wiki but public.

Krd added a subscriber: Krd.Apr 14 2015, 9:56 AM

In the meantime, it sounds like the functionality OTRS wiki is looking for can be done with a (large and constantly updating..) set of whitelisted pages?

Patrick and other admins: Do you think this would be a good interim solution? (does it meet the goals for now?) Though a bit more cumbersome I and others can certainly help to keep the list up to date. I think the most important question is if the documentation pages would work still on otrs-wiki but public.

Can you clarify how a whitelisted page would work on a fishbowl wiki? Will all users have access to all pages by default or will some users be restricted to whitelisted pages only or...

Thanks.

In the meantime, it sounds like the functionality OTRS wiki is looking for can be done with a (large and constantly updating..) set of whitelisted pages?

Patrick and other admins: Do you think this would be a good interim solution? (does it meet the goals for now?) Though a bit more cumbersome I and others can certainly help to keep the list up to date. I think the most important question is if the documentation pages would work still on otrs-wiki but public.

Can you clarify how a whitelisted page would work on a fishbowl wiki? Will all users have access to all pages by default or will some users be restricted to whitelisted pages only or...
Thanks.

Someone can correctly me if I'm wrong but essentially the whitelisted pages (the documentation etc) would be 'fishbowl' in that they can't be edited but anyone can visit them. If you attempt to go to a page that is not white listed you will be prompted to log in. Essentially the way to think about it is that these pages would becomes similar to the OTRS wiki Main Page (which is a white listed page). Each white listed page needs to be added specifically to the list and so any page not on that list would require log in (so 'default private' ).

Krenair renamed this task from Enable Extension:Lockdown on OTRS Wiki to Deploy Extension:Lockdown to the cluster and enable on OTRS Wiki.Aug 12 2015, 1:18 AM
Krenair removed a project: Wikimedia-Site-requests.

Ping on this?

I also would prefer the whitelist solution (With $wgWhitelistReadRegexp we could even make it so there is a "public" namespace)

Someone can correctly me if I'm wrong but essentially the whitelisted pages (the documentation etc) would be 'fishbowl' in that they can't be edited but anyone can visit them. If you attempt to go to a page that is not white listed you will be prompted to log in. Essentially the way to think about it is that these pages would becomes similar to the OTRS wiki Main Page (which is a white listed page). Each white listed page needs to be added specifically to the list and so any page not on that list would require log in (so 'default private' ).

That's correct. One important thing to add, is that all users (including logged out) will be able to view the whitelisted pages. They will also be able to view old versions of any public page, and the ?action=history of public pages. Its basically the exact same as how https://otrs-wiki.wikimedia.org/wiki/Main_Page works, except making other pages act like Main_Page.

MarcoAurelio triaged this task as Lowest priority.Nov 23 2017, 9:12 PM

I'm taking the liberty to triage this as lowest priority to reflect the, IMHO, current status of this task.

Bawolff closed this task as Declined.Nov 24 2017, 2:29 AM

Nobody responded in a year and a half. Im going to mark this declined. If at some future point someone wants this please reopen the bug.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptNov 24 2017, 2:29 AM