Wikitech-l August 2013

wikitech-l@lists.wikimedia.org

133 participants
130 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 17 Jun '24

17 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

2 2

MediaWiki 1.19.0beta2
by Sam Reed 09 May '14

09 May '14

I'm happy to announce the availability of the second beta release of the new MediaWiki 1.19 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.19 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES-1.19 file for the full list of changes in this version. Five security issues were discovered. It was discovered that the api had a cross-site request forgery (CSRF) vulnerability in the block/unblock modules. It was possible for a user account with the block privileges to block or unblock another user without providing a token. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212 It was discovered that the resource loader can leak certain kinds of private data across domain origin boundaries, by providing the data as an executable JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of CSRF protection tokens. This allows compromise of the wiki's user accounts, say by changing the user's email address and then requesting a password reset. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907 Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF) vulnerability in Special:Upload. Modern browsers (since at least as early as December 2010) are able to post file uploads without user interaction, violating previous security assumptions within MediaWiki. Depending on the wiki's configuration, this vulnerability could lead to further compromise, especially on private wikis where the set of allowed file types is broader than on public wikis. Note that CSRF allows compromise of a wiki from an external website even if the wiki is behind a firewall. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317 George Argyros and Aggelos Kiayias reported that the method used to generate password reset tokens is not sufficiently secure. Instead we use various more secure random number generators, depending on what is available on the platform. Windows users are strongly advised to install either the openssl extension or the mcrypt extension for PHP so that MediaWiki can take advantage of the cryptographic random number facility provided by Windows. Any extension developers using mt_rand() to generate random numbers in contexts where security is required are encouraged to instead make use of the MWCryptRand class introduced with this release. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078 A long-standing bug in the wikitext parser (bug 22555) was discovered to have security implications. In the presence of the popular CharInsert extension, it leads to cross-site scripting (XSS). XSS may be possible with other extensions or perhaps even the MediaWiki core alone, although this is not confirmed at this time. A denial-of-service attack (infinite loop) is also possible regardless of configuration. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315 ********************************************************************* What's new? ********************************************************************* MediaWiki 1.19 brings the usual host of various bugfixes and new features. Comprehensive list of what's new is in the release notes. * Bumped MySQL version requirement to 5.0.2. * Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work. * New skins/common/*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css. * The default user signature now contains a talk link in addition to the user link. * Searching blocked usernames in block log is now clearer. * Better timezone recognition in user preferences. * Extensions can now participate in the extraction of titles from URL paths. * The command-line installer supports various RDBMSes better. * The interwiki links table can now be accessed also when the interwiki cache is used (used in the API and the Interwiki extension). Internationalization - -------------------- * More gender support (for instance in user lists). * Add languages: Canadian English. * Language converter improved, e.g. it now works depending on the page content language. * Time and number-formatting magic words also now depend on the page content language. * Bidirectional support further improved after 1.18. Release notes - ------------- Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE LEASE-NOTES-1.19;hb=1.19.0beta2 https://www.mediawiki.org/wiki/Release_notes/1.19 Co-inciding with these security releases, the MediaWiki source code repository has moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3) to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the relevant commits for these releases will not be appearing in our SVN repository. If you use SVN checkouts of MediaWiki for version control, you need to migrate these to Git. If you up are using tarballs, there should be no change in the process for you. Please note that any WMF-deployed extensions have also been migrated to Git also, along with some other non WMF-maintained ones. Please bear with us, some of the Git related links for this release may not work instantly, but should later on. To do a simple Git clone, the command is: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git More information is available at https://www.mediawiki.org/wiki/Git For more help, please visit the #mediawiki IRC channel on freenode.net irc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list at mediawiki-l(a)lists.wikimedia.org. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz Patch to previous version (1.19.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si g http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz. sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz.sig Public keys: https://secure.wikimedia.org/keys.html

5 5

Re: [Wikitech-l] [WikimediaMobile] Wikimedia Commons mobile photo uploader app updated on iOS and Android
by rupert THURNER 05 Mar '14

05 Mar '14

On Sun, Aug 25, 2013 at 7:46 PM, Yuvi Panda <yuvipanda(a)gmail.com> wrote: > Hey rupert! > > On Sun, Aug 25, 2013 at 10:21 PM, rupert THURNER > <rupert.thurner(a)gmail.com> wrote: >> hi brion, >> >> thank you so much for that! where is the source code? i tried to >> search for "commons" on https://git.wikimedia.org/. i wanted to look > > Android: https://git.wikimedia.org/summary/apps%2Fandroid%2Fcommons.git > iOS: github.com/wikimedia/Commons-iOS > >> if there is really no account creation at the login screen or it is >> just my phone which does not display one, and which URL the aplication > > Mediawiki doesn't have API support for creating accounts, and hence > the apps don't have create account support yet. created https://bugzilla.wikimedia.org/show_bug.cgi?id=53328, maybe you could detail a little bit more how this api should look like? rupert.

4 8

Welcome to Ken Snider, Wikimedia Operations
by Erik Moeller 28 Jan '14

28 Jan '14

Hello all, I’m delighted to announce that Ken Snider is joining the Wikimedia operations team. He will start as an international contractor working remotely from Toronto, Canada on June 10, and will be visiting SF in the week of June 17. We’re currently in the process of seeking work authorization in the United States in the Director of TechOps position. CT has graciously agreed to support the ops leadership transition full-time through June, and part-time through July. We’ll be starting the handover while Ken is working remotely. A bit more about Ken: Ken was apparently genetically predisposed to become a sysadmin since he joined one of Canada’s first large ISPs, Primus, straight out of school in 1997 and helped build their infrastructure til 2001. He then joined a startup called OpenCOLA in 2001 which was co-founded by Cory Doctorow and developed early P2P precursors to tools like BitTorrent and Steam. It’s best known today for the development of an open source (GPL’d) cola recipe which is still in use (more than 150,000 cans sold if Wikipedia is to be believed). Ken got involved in one of Cory’s pet projects, BoingBoing.net which some of you may have heard of ;-), and has been their sysadmin since 2003. After a stint from 2001-2005 at DataWire, Ken became Director of Tech Ops at Federated Media, a role he held from 2005-2012. Federated Media is an ad network that was founded to support high traffic blogs and sites that want to stay independent of large publishers, with a network that supports more than 1B requests/day. One of the unusual challenges at FM was that the company grew through acquisitions of various blogging and publishing networks. This led to the challenge of integrating very heterogeneous operations and engineering infrastructure, including multiple geographically distributed ops teams and data-center locations. As DTO, Ken led these efforts, such as OS standardization, development of a unified deployment infrastructure, etc. Ken also ensured that the operations group partnered effectively with the various engineering teams developing site features and enhancements. I want to again take this opportunity to thank CT Woo for his tireless operations leadership since December 2010. I’d also like to thank everyone who’s participated in the Director of TechOps search process. Please join me in welcoming Ken to the Wikimedia Foundation and the community. :-) All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

4 4

!ask
by Ori Livneh 24 Jan '14

24 Jan '14

Can we deprecate usage of '!ask' on IRC? > ori-l: !ask > wm-bot: Hi, how can we help you? Just ask your question. It's annoying when people ask to ask, but the people who do so do it out of insecurity or lack of experience, and so they're the last people we should be siccing our bots on. I've used '!ask' a lot before but I'm going to stop. I hope others do the same.

9 10

migrating hooks doc to doxygen?
by Antoine Musso 13 Nov '13

13 Nov '13

Hello, Since we introduced hooks in MediaWiki, the documentation has been maintained in a flat file /docs/hooks.txt . Over the week-end I have converted the content of that file to let Doxygen recognize it. The patchset is: https://gerrit.wikimedia.org/r/#/c/66128/ I have used that patch to generate a temporary documentation. That lets everyone browse the result easily. The produced result is: A landing page: https://doc.wikimedia.org/mw-hooks/hooks_mainpage.html The doc overview: https://doc.wikimedia.org/mw-hooks/page_hooks_documentation.html A list of hooks with their documentation: https://doc.wikimedia.org/mw-hooks/page_hooks_list.html I think that makes it a bit more accessible to everyone and Doxygen autolink to referenced classes. Some issues I have: - the hooks are listed alphabetically when they could be regrouped by theme (like API, SpecialPages, HTML Forms ...). - The hooks are documented in a separate file (still docs/hooks.txt), when we might want to have the doc near the wfRunHooks() call. Thoughts ? -- Antoine "hashar" Musso

13 17

New git-review lets you configure 'origin' as the gerrit remote
by Ori Livneh 22 Oct '13

22 Oct '13

Hey, The new version of git-review released today (1.22) includes a patch I wrote that makes it possible to work against a single 'origin' remote. This amounts to a workaround for git-review's tendency to frighten you into thinking you're about to submit more patches than the ones you are working on. It makes git-review more pleasant to work with, in my opinion. To enable this behavior, you first need to upgrade to the latest version of git-review, by running "pip install -U git-review". Then you need to create a configuration file: either /etc/git-review/git-review.conf (system-wide) or ~/.config/git-review/git-review.conf (user-specific). The file should contain these two lines: [gerrit] defaultremote = origin Once you've made the change, any new Gerrit repos you clone using an authenticated URI will just work. You'll need to perform an additional step to migrate existing repositories. In each repository, run the following commands: git remote set-url origin $(git config --get remote.gerrit.url) git remote rm gerrit git review -s Hope you find this useful.

13 15

Can we help Tor users make legitimate edits?
by Sumana Harihareswara 28 Sep '13

28 Sep '13

TL;DR: A few ideas follow on how we could possibly help legit editors contribute from behind Tor proxies. I am just conversant enough with the security problems to make unworkable suggestions ;-), so please correct me, critique & suggest solutions, and perhaps volunteer to help. The current situation: https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor_to_bypass… We generally don't let anyone edit or upload from behind Tor; the TorBlock extension stops them. One exception: a person can create an account, accumulate lots of good edits, and then ask for an IP block exemption, and then use that account to edit from behind Tor. This is unappealing because then there's still a bunch of in-the-clear editing that has to happen first, and because then site functionaries know that the account is going to be making controversial edits (and could possibly connect it to IPs in the future, right?). And right now there's no way to truly *anonymously* contribute from behind Tor proxies; you have to log in. However, since JavaScript delivery is hard for Tor users, I'm not sure how much editing from Tor -- vandalism or legit -- is actually happening. (I hope for analytics on this and thus added it to https://www.mediawiki.org/wiki/Analytics/Dreams .) We know at least that there are legitimate editors who would prefer to use Tor and can't. People have been talking about how to improve the situation for some time -- see http://cryptome.info/wiki-no-tor.htm and https://lists.torproject.org/pipermail/tor-dev/2012-October/004116.html . It'd be nice if it could actually move forward. I've floated this problem past Tor and privacy people, and here are a few ideas: 1) Just use the existing mechanisms more leniently. Encourage the communities (Wikimedia & Tor) to use https://en.wikipedia.org/wiki/Wikipedia:Request_an_account (to get an account from behind Tor) and to let more people get IP block exemptions even before they've made any edits (< 30 people have gotten exemptions on en.wp in 2012). Add encouraging "get an exempt account" language to the "you're blocked because you're using Tor" messaging. Then if there's an uptick in vandalism from Tor then they can just tighten up again. 2) Encourage people with closed proxies to re-vitalize https://en.wikipedia.org/wiki/Wikipedia:WOCP . Problem: using closed proxies is okay for people with some threat models but not others. 3) Look at Nymble - http://freehaven.net/anonbib/#oakland11-formalizing and http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php . It would allow Wikimedia to distance itself from knowing people's identities, but still allow admins to revoke permissions if people acted up. The user shows a real identity, gets a token, and exchanges that token over tor for an account. If the user abuses the site, Wikimedia site admins can blacklist the user without ever being able to learn who they were or what other edits they did. More: https://cs.uwaterloo.ca/~iang/ Ian Golberg's, Nick Hopper's, and Apu Kapadia's groups are all working on Nymble or its derivatives. It's not ready for production yet, I bet, but if someone wanted a Big Project.... 3a) A token authorization system (perhaps a MediaWiki extension) where the server blindly signs a token, and then the user can use that token to bypass the Tor blocks. (Tyler mentioned he saw this somewhere in a Bugzilla suggestion; I haven't found it.) 4) Allow more users the IP block exemption, possibly even automatically after a certain number of unreverted edits, but with some kind of FlaggedRevs integration; Tor users can edit but their changes have to be reviewed before going live. We could combine this with (3); Nymble administrators or token-issuers could pledge to review edits coming from Tor. But that latter idea sounds like a lot of social infrastructure to set up and maintain. Thoughts? Are any of you interested in working on this problem? #tor on the OFTC IRC server is full of people who'd be interested in talking about this. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

16 25

Advance notice: I'm taking a sabbatical October-December
by Sumana Harihareswara 27 Sep '13

27 Sep '13

I've been accepted to Hacker School <https://www.hackerschool.com>, a writers' retreat for programmers in New York City. I will therefore be taking an unpaid personal leave of absence from the Wikimedia Foundation via our sabbatical program. My last workday before my leave will be Friday, September 27. I plan to be on leave all of October, November, and December, returning to WMF in January. During my absence, Quim Gil will be the temporary head of the Engineering Community Team. Thank you, Quim! I'll spend much of September turning over responsibilities to him. Over the next month I'll be saying no to a lot of requests so I can ensure I take care of all my commitments by September 27th, when I'll be turning off my wikimedia.org email. If there's anything else I can do to minimize inconvenience, please let me know. And -- I have to say this -- oh my gosh I'm so excited to be going to Hacker School in just a month! Going from "advanced beginner" to confident programmer! Learning face-to-face with other coders, 30-45% of them women, all teaching each other! Thank you, WMF, for the sabbatical program, and thanks to my team for supporting me on this. I couldn't do this without you. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

5 7

MediaWiki-Vagrant: new features
by Ori Livneh 26 Sep '13

26 Sep '13

Hello, I'm writing to tell you about some cool new MediaWiki-Vagrant features. MediaWiki-Vagrant now ships with a custom Vagrant plug-in that augments the default 'vagrant' command-line tool with some additional sub-commands that are specifically designed to make MediaWiki development more productive and fun. The most important addition is a set of four sub-commands for managing roles. (Roles, you'll recall, are optional software stacks that MediaWiki-Vagrant can configure automatically. There's a VisualEditor role, a Scribunto role, a qa/browsertests role, etc.) The new commands are: $ vagrant list-roles Lists available roles. Currently enabled roles are marked with a '*'. $ vagrant enable-role Enables a role. Example: 'vagrant enable-role visualeditor'. $ vagrant disable-role <name> Disables a role. $ vagrant reset-roles Disable all roles. There's a short, 1-minute screencast up at http://ascii.io/a/4428demonstrating usage. Check it out. I'll wait. The other cool sub-command that was recently added is 'vagrant run-tests'. Any command-line arguments following 'run-tests' are passed through to PHPUnit running on the VM, so it's possible to run (for example) 'vagrant run-tests extensions/EventLogging'. Finally, there's 'vagrant puppet-paste'. This uploads the log of your most recent Puppet run to < dpaste.de> and prints out a URL. This is primarily intended as a debugging aid. Additional documentation, including installation help, is up at < https://www.mediawiki.org/wiki/MediaWiki-Vagrant>. Please report any bugs you encounter at < https://bugzilla.wikimedia.org/enter_bug.cgi?product=Tools&component=Vagrant >. Ori

5 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l August 2013