[Wikitech-l] Wednesday: Technical Advice IRC Meeting
Sorry for cross-posting! Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 3-4 pm UTC** on #wikimedia-tech. The Technical Advice IRC meeting is open for all volunteer developers, topics and questions. This can be anything from "how to get started" over "who would be the best contact for X" to specific questions on your project. If you know already what you would like to discuss or ask, please add your topic to the next meeting: https://www.mediawiki.org/wiki /Technical_Advice_IRC_Meeting Hope to see you there! Michi (for WMDE’s tech team) -- Michael F. Schönitzer Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen Wissens frei teilhaben kann. Helfen Sie uns dabei! http://spenden.wikimedia.de/ Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role
Regarding "Mandatory code review (especially with a required waiting time) and mandatory reauthentication are far more invasive than removing JS editing permissions from administrators who don't want them.": I think that mandatory code review and mandatory authentication would be far less costly and far faster to implement in terms of volunteer time spent redesigning social processes and managing permissions. These options both sound good to me. In the longer term, I am thinking about how to implement a new permission as you suggest. The more that I think about it, the more that I believe that it could be done with less time cost to volunteers than I originally was dreading. For example, the new permission could be locally assignable by stewards upon community request, similar to bureaucrat permissions. A month-long RFC with adequate translations would likely be sufficient to surface most major unintended side effects and to surface suggestions for design modifications. Regarding "I feel most people don't appreciate how *extremely* scary the current situation is. The public backlash around the Seigenthaler affair was sparked by Wikipedia carelessly causing harm to a single individual. It would be child's play compared to what would happen if a few ten thousand people had their bank accounts cleaned, or a few dozen opposition members arrested by the secret police, or something like that, because Wikipedians decided security improvements were not worth the effort of moving users from one group to another.": unless I have overlooked something, there seems to be consensus in this thread that changes are worth considering, and people are discussing which changes to make and in what order. People are trying to be helpful, and please keep that in mind. Pine ( https://meta.wikimedia.org/wiki/User:Pine ) null ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making PolyGerrit the default ui for gerrit
Delaying until after the sre offsite. On Tuesday, 12 June 2018, 17:42:02 BST, Paladox wrote: We will have to change the date to friday as no ops will be around next week (from monday) for there offsite. On Monday, 11 June 2018, 18:55:59 BST, Paladox wrote: The date to switch the default ui is next monday (18/06/18) which will give users plenty of time to give there opinion. Users can still switch back to the old ui just the new ui is secure. https://phabricator.wikimedia.org/T196812#4273184 On Monday, 11 June 2018, 13:38:20 BST, Paladox wrote: Hi, i have created this task [1] with i have uploaded this patch [2] to make polygerrit the default ui. The reason why is upstream are preparing to remove the gwtui very soon. In matter of fact upstream have disabled the gwtui on *.googlesource.com. Upstream already have this change [3] to remove the ui. Making PolyGerrit the default ui will get new users use to the new ui. GWTUI will still be available with ui switcher in the footer or you can append the url like https://gerrit.wikimedia.org/r/?polygerrit=0 PolyGerrit is stable, secure and also fast. It also has features that you cannot see in gwtui like user status, naming your patchiest (description), cc feature and also being able to tell who added you as a reviewer. This email is advanced notice before we change the default ui. any bugs todo with polygerrit / gerrit can be filled at https://phabricator.wikimedia.org/project/view/330/ and we can forward it upstream. [1] https://phabricator.wikimedia.org/T196812 [2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444 [3] https://gerrit-review.googlesource.com/c/gerrit/+/116790 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making PolyGerrit the default ui for gerrit
We will have to change the date to friday as no ops will be around next week (from monday) for there offsite. On Monday, 11 June 2018, 18:55:59 BST, Paladox wrote: The date to switch the default ui is next monday (18/06/18) which will give users plenty of time to give there opinion. Users can still switch back to the old ui just the new ui is secure. https://phabricator.wikimedia.org/T196812#4273184 On Monday, 11 June 2018, 13:38:20 BST, Paladox wrote: Hi, i have created this task [1] with i have uploaded this patch [2] to make polygerrit the default ui. The reason why is upstream are preparing to remove the gwtui very soon. In matter of fact upstream have disabled the gwtui on *.googlesource.com. Upstream already have this change [3] to remove the ui. Making PolyGerrit the default ui will get new users use to the new ui. GWTUI will still be available with ui switcher in the footer or you can append the url like https://gerrit.wikimedia.org/r/?polygerrit=0 PolyGerrit is stable, secure and also fast. It also has features that you cannot see in gwtui like user status, naming your patchiest (description), cc feature and also being able to tell who added you as a reviewer. This email is advanced notice before we change the default ui. any bugs todo with polygerrit / gerrit can be filled at https://phabricator.wikimedia.org/project/view/330/ and we can forward it upstream. [1] https://phabricator.wikimedia.org/T196812 [2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444 [3] https://gerrit-review.googlesource.com/c/gerrit/+/116790 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [MediaWiki-l] git review warnings
On Tue, Jun 12, 2018 at 5:03 AM Martin Urbanec wrote: > The second one is caused by Gerrit update. Upstream kept refs/publish/* > working, because they know git-review is using that ref. I think that as > soon as git-review developers fixes this and you will upgrade, the warning > will disappear. > > Yeah, I guess refs/publish/* is being deprecated. Which is pretty funny, considering refs/for/* was going to be deprecated in favor of the newer refs/publish/*. Later, that was deemed to be a bad idea and so the new one was deprecated and the original retained. Any scripts that use refs/publish/* should be updated. I assume git-review will do this in short order. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?
On Fri, Jun 8, 2018 at 7:02 AM Alex Monk wrote: > I think Gerrit admin permissions were abused to remove the review > > https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_remove_reviewer Anyone who is a project owner on mediawiki/* could have done it, it had nothing to do with admin permissions. But that's not the point of this thread at all... -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?
On Fri, Jun 8, 2018 at 12:19 AM MZMcBride wrote: > Yaron Koren wrote: > >That's how it went until two days ago, when Antoine Musso submitted a > >patch for my Site Settings extension (I don't know why that one > >specifically), re-adding the file. I rejected the patch, on the same > >grounds as before, but another developer, Chad Horohoe, overrode me and > >merged it in. That led to a discussion featuring Antoine, Chad, a few > >other WMF developers, and me, which you can find here: > > > >https://gerrit.wikimedia.org/r/#/c/437555/ > > > >Some of the (unbelievable) highlights: > > > >- From Antoine: "Well then can we just archive this repository please?" > > > >- From Chad: "Yeah no that's not how it works. If it's being hosted on > >gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can > >find hosting elsewhere." > > It was really inappropriate for Chad to hastily and forcefully merge this > change. > > Probably. I was in a pretty crappy mood and I went "not again" and merged it. I don't actually care one way or the other if repos have the file (nb: I support the CoC), but I just want to be **consistent** If we're gonna have them: have them everywhere. If not, then we should be removing them everywhere. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role
On Tue, Jun 12, 2018 at 8:56 AM Federico Leva (Nemo) wrote: > Personally I'd like us to explore agnostic and non-invasive solutions. > Mandatory code review (especially with a required waiting time) and mandatory reauthentication are far more invasive than removing JS editing permissions from administrators who don't want them. That's not to say they shouldn't be done (again, most of the things we could do are complimentary, and pretty much anything we could do we should do, given the crazy levels of risk involved), but they require more nuance and experimentation. The subdivision of permissions across more user groups relies on a > number of assumptions which may not hold. For instance, on thousands of > MediaWiki wikis there's only one sysop anyway. > I presume you are talking about non-Wikimedia wikis here, as Wikimedia has less then a thousand wikis (and about half of them seem to do basically zero Javascript editing and so wouldn't be inconvenienced by not having any permissions to do so and having to call in crosswiki helpers, like they do for vandalism). For small MediaWiki installations this change offers little extra defense but they are not particularly interesting attack targets in the first place. For large non-Wikimedia wikis the change will be helpful the same way it is for Wikimedia. Something I would like is the ability to "have" a permission, but only > "activate" it for limited periods of time when needed. The activation > could require some extra steps (e.g. inserting the password again). It > could be logged to Special:Log, which people can then monitor as they > wish. A separate countermeasure (other than deflag) could inhibit it. > I agree reauthenticating before using more powerful or dangerous permissions is something to look into, and there is ongoing work on that front. But again the UX implications are nontrivial (what happens if the timer runs out while you are editing the page?) and again there is no reason not to do both. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role
On Tue, Jun 12, 2018 at 3:26 AM Nathan wrote: > Is the risk of an attacker taking over an account with CSS/JS edit > permissions any more or less because that person knows how to use CSS/JS? > I tried to address this in the FAQ: > * The number of accounts which can be used to compromise the site will be drastically reduced. Less accounts that can serve as attack vectors means a smaller chance chance of an account being vulnerable when the password database of some third-party website gets compromised. A smaller number of accounts is also easier to monitor for suspicious logins. > * Beyond the mere numbers of accounts, it will remove the most vulnerable accounts as attack vectors. Users who can write CSS/JS code probably have better IT skills in general, and thus better password and system security practices." Can we make the > edit right temporary, so someone can request it through a normal simple > process, execute their edits, and then relinquish it? It can be a right > that admins could grant to each other, as long as they can't gift it to > themselves. > We can (with some work), and we should. The various ways to make deploying malicious javascript harder are complimentary, and we should do them all. Separating permissions just happens to be the easiest one. I feel most people don't appreciate how *extremely* scary the current situation is. The public backlash around the Seigenthaler affair was sparked by Wikipedia carelessly causing harm to a single individual. It would be child's play compared to what would happen if a few ten thousand people had their bank accounts cleaned, or a few dozen opposition members arrested by the secret police, or something like that, because Wikipedians decided security improvements were not worth the effort of moving users from one group to another. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [MediaWiki-l] git review warnings
Sending a copy to wikitech-l, because this is a little bit more generic than "just" MediaWiki. Hello, the first one means you have something in /etc/git-review/git-review.conf, which is probably unneeded. I suggest you to delete that file. On my system, it doesn't exist. The second one is caused by Gerrit update. Upstream kept refs/publish/* working, because they know git-review is using that ref. I think that as soon as git-review developers fixes this and you will upgrade, the warning will disappear. Best, Martin út 12. 6. 2018 v 0:51 odesílatel Huji Lee napsal: > Every time I submit a patch to gerrit using the git review command, I get > two warning messages that I ignore. I just want to make sure that I can > continue to safely ignore them (or else, how to get rid of them). > > The first one says: > Using global/system git-review config files > (/etc/git-review/git-review.conf) is deprecated > > The second one says: > remote: Pushing to refs/publish/* is deprecated, use refs/for/* > instead. > > Thanks, > Huji > ___ > MediaWiki-l mailing list > To unsubscribe, go to: > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role
Personally I'd like us to explore agnostic and non-invasive solutions. The subdivision of permissions across more user groups relies on a number of assumptions which may not hold. For instance, on thousands of MediaWiki wikis there's only one sysop anyway. Something I would like is the ability to "have" a permission, but only "activate" it for limited periods of time when needed. The activation could require some extra steps (e.g. inserting the password again). It could be logged to Special:Log, which people can then monitor as they wish. A separate countermeasure (other than deflag) could inhibit it. Granular permissions are tricky on MediaWiki, but we might come up with simple implementations. Maybe, set a rate limit to 0 and add a special page to temporarily increase it for yourself (or others). Something like that. Federico ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
