Page MenuHomePhabricator

ldap/wmf group should not have +2 in Gerrit
Open, MediumPublic

Description

As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit. This is a flawed design and should be corrected.

Details

Reference
bz60412

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:01 AM
bzimport added a project: Gerrit.
bzimport set Reference to bz60412.
bzimport added a subscriber: Unknown Object (MLST).

Gerrit is a flawed design.

(In reply to comment #0)

As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit.
This is a flawed design and should be corrected.

Not automatically. I can't +2 code. Not that I actually want the ability to be able to, though.

(In reply to comment #1)

Gerrit is a flawed design.

Perhaps, but it's the current code review tool. :-)

Further information about the technical details behind the current implementation would be really helpful here. It has something to do with LDAP and user groups or something, I think, maybe.

(In reply to comment #0)

As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit.
This is a flawed design and should be corrected.

Rephrase this: any full time WMF engineer is entitled to access to the ldap/wmf group (ops has +2 on all repos). Like Dan says: non engineers don't usually get this (and actually this is a nice reminder--I need to remove some former staffers and hadn't gotten around to it)

ldap/wmf is given review permissions over most non-operations stuff. Specifically wikimedia/* mediawiki/* and analytics/*. This is mostly done out of convenience as there's lots of deployed things that an engineer could need access to.

If a given repo has a desire to deny default group permissions from inheriting, they can in their ACL(s).

(In reply to comment #4)

(In reply to comment #0)

As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit.
This is a flawed design and should be corrected.

Rephrase this: any full time WMF engineer is entitled to access to the
ldap/wmf
group (ops has +2 on all repos).

That should say "entitled... on request." It's not automatically granted, and it typically *doesn't* get granted until an engineer finds themselves needing it and ask :)

(In reply to comment #4)

Thanks for the clarification!

Rephrase this: any full time WMF engineer is entitled to access to the
ldap/wmf group (ops has +2 on all repos).

Is there a way to see the members of the ldap/wmf group?

As I understand it, this ldap/wmf group includes more than just full-time Wikimedia Foundation engineers. There are contractors in this group. There are non-engineers in this group.

Related: https://gerrit.wikimedia.org/r/#/admin/groups/11,members

(In reply to comment #6)

Is there a way to see the members of the ldap/wmf group?

https://gerrit.wikimedia.org/wmf-20140124.txt

I tried to clarify the bug summary.

Why are we relying on the ldap/wmf group? Can't we simply be explicit (i.e., https://gerrit.wikimedia.org/r/#/admin/groups/11,members)?

This would be much more transparent.

demon added a comment.Jan 25 2014, 1:00 AM

(In reply to comment #8)

I tried to clarify the bug summary.

Why are we relying on the ldap/wmf group? Can't we simply be explicit (i.e.,
https://gerrit.wikimedia.org/r/#/admin/groups/11,members)?

Because as far as I know, it's also used for access to some other services too (I think the test logstash is an example, as it's still under development and contains private logs). It's modeled after the ldap/ops group, which has existed since labs launched.

It's used in gerrit mostly out of convenience, but I could be convinced otherwise if we can't do this \/

This would be much more transparent.

I would love to make the ldap groups (and everything about ldap) much much more accessible on wikitech. There's not a whole lot of private data there.

(In reply to comment #8)

Can't we simply be explicit (i.e.,
https://gerrit.wikimedia.org/r/#/admin/groups/11,members)?

With or without the current [[+2]] approval process that currently entails? (Both cases would require process changes...)

(In reply to comment #9)

Because as far as I know, it's also used for access to some other services
too
(I think the test logstash is an example, as it's still under development and
contains private logs). It's modeled after the ldap/ops group, which has
existed since labs launched.

I don't think there's any need to rethink this LDAP group from scratch. I think most if not all the people in the group who ever used +2 also had such permission via other groups (particularly for "their" extensions). It would be nice to have

  1. a list of group members who ever used +2,
  2. a list for the subset of (1) which could perform said +2 thanks to wmf group only.

From that we can understand how big a change this would be. We might discover we only need a handful tweaks to some more specific groups' membership.

Whatever you decide to do, I would seriously suggest an email informing everyone that this happened (if that email went out and I didn't notice, ignore the entirety of this comment).

I accidentally discovered I had +2 today. Luckily I was not stupid enough to hit the button, but: I really shouldn't have +2. This place is not paranoid enough about my competence for me to be comfortable ;p.

demon added a comment.Dec 15 2014, 8:06 PM

Whatever you decide to do, I would seriously suggest an email informing everyone that this happened (if that email went out and I didn't notice, ignore the entirety of this comment).

I accidentally discovered I had +2 today. Luckily I was not stupid enough to hit the button, but: I really shouldn't have +2. This place is not paranoid enough about my competence for me to be comfortable ;p.

That what happened? Nothing changed :)

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2015, 8:54 AM
Nemo_bis triaged this task as Medium priority.Sep 4 2015, 7:06 AM
Nemo_bis set Security to None.

While this group is being handed out to people purely so they can access stuff like logstash, it shouldn't be implying full code review rights on random repositories, and certainly not mediawiki/*.

The current list is at wikitech:LDAP Groups

Catrope removed a subscriber: Catrope.Nov 13 2015, 7:58 PM
demon moved this task from Bugs & stuff to Repo Admin on the Gerrit board.Jul 25 2016, 6:09 PM
Bawolff added a subscriber: Bawolff.Feb 3 2017, 8:24 AM

This would be much more transparent.

There is also a transparency benefit of keeping separate groups for people who have +2 rights due to community process vs due to WMF employment.

Is there a way to see the members of the ldap/wmf group?

I created https://tools.wmflabs.org/ldap/group/wmf to make the list more easily accessible.

This would be much more transparent.

There is also a transparency benefit of keeping separate groups for people who have +2 rights due to community process vs due to WMF employment.

Yes, it's also a protection for the persons involved. I think the cost of requesting +2 explicitly when needed (which is not always) is much lower than the benefit of having a publicly logged rationale.

I created https://tools.wmflabs.org/ldap/group/wmf to make the list more easily accessible.

Great! Do we also need a list of those who in the last year (?) used +2 in a repository they don't have access to by other means, to assess impact?

If someone is missing from an extension-XX group which owns an extension they often use +2 for, by the way, it's valuable to add them also to help code review (because you can add the entire group to reviewers without knowing who they are).