Wikitech-l August 2013

wikitech-l@lists.wikimedia.org

133 participants
134 discussions

Bugzilla: Separate bug report status when patch is in Gerrit?
by Andre Klapper 27 Aug '13

27 Aug '13

Hi everybody, in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3]. >From the Amsterdam Hackathon I know that some developers would like to filter on bug reports that have or don't have a patch in Gerrit, and easier finding of bug reports with a corresponding patch && lack of recent changes might provide another entry point for new developers (pick up the existing patch and finish it). Hence I propose * to remove the manually set and error-prone Bugzilla keyword "patch-in-gerrit": Every bug on its way to get RESOLVED FIXED has to pass this stage anyway so a status feels more appropriate, and * to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit. Comments? andre [1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html [2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322 PS: Making the Gerrit notification bot automatically close bug reports in Bugzilla after merging a patch in Gerrit, or differentiating in Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix deployed on the Wikimedia wikisites) are also interesting topics to discuss at some point, but not in this thread. One step at a time. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

13 21

Javascript to find other articles having the same external link
by Lars Aronsson 27 Aug '13

27 Aug '13

By putting the following code (written by User:EnDumEn) in user:YOURNAME/common.jsany external link gets an extra little symbol (⎆), which leads to a link search for that link. This is very useful for finding other articles that cite the same source. jQuery( "a.external" ).after( function() { return jQuery( "<a>⎆</a>)" ) .attr( "href", "//sv.wikipedia.org/wiki/Special:Linksearch/" + this.href ) .before( " " ); }); -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

6 6

Wikimedia Commons mobile photo uploader app updated on iOS and Android
by Brion Vibber 27 Aug '13

27 Aug '13

We have just released Commons for iOS (version 1.0.8) and Android (1.0beta11), with *major* UI and performance improvements on iOS and minor bug fixes on Android. This is our first release in a couple months on iOS -- we hoped to have one out before Wikimania but were delayed due to problems with Apple's online developer tools being offline for a while. There are huge UI improvements and lots of bug fixes, thanks to our new mobile developer Monte Hurd. Thanks Monte! We've been releasing smaller updates on Android in the meantime, so the updates have been more incremental there. Both versions now include a quick 3-screen acceptable-use tutorial on first login. iOS includes featured photos as examples as well; this will come to Android in a future version. Downloads and release notes: * Apple App Store: https://itunes.apple.com/us/app/wikimedia-commons/id630901780 * Google Play: https://play.google.com/store/apps/details?id=org.wikimedia.commons * Android direct download: http://download.wikimedia.org/android/wikimedia-commons-1.0beta11.apk -- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org)

7 8

Weighted random article
by Lars Aronsson 27 Aug '13

27 Aug '13

The Swedish Wikipedia now has more than 1.5 million articles, compared to 600,000 in January 2013 and 500,000 in September 2012. This is due to the creation by a bot of many articles on animal and plant species. The Swedish Wikipedia community has discussed the matter thoroughly, and there is strong consensus to keep these articles and to keep on generating more. (It is known that many German wikipedians think these are bad articles that should be removed, but this is not their decision.) The current implementation of [[Special:Random]], however, gives equal weight to every existing article and this is perceived as a problem that needs to be fixed. But it is not obvious how a bug report or feature request should be written. A naive approach would be to ask for a random article that wasn't created by a bot, but this is not to the point. Users want bot generated articles to come up, only not so often. And some manually written article stubs are also less wanted. Perhaps the random function should be weighted by article length or by the number of page views? But is it practical to implement such a weighted random function? Are the necessary data in the database? -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

8 10

Feedback/testing wanted: SecureLogin on test2.wikipedia.org
by Greg Grossmeier 27 Aug '13

27 Aug '13

Hello all, We have enabled the newly updated SecureLogin on http://test2.wikipedia.org Big thanks to Chris and Chad getting this work finalized on Friday and taking a bit of their weekend today/tomorrow. This is the work described here: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security The "plan of record" for what the various questions is summarized here: http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071441.html (also in above RFC) Go forth and test! Provide feedback! Reply here and/or report bugs, please. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

3 2

MediaWiki's Login Security
by Chris Steipp 27 Aug '13

27 Aug '13

Hi all, With all the talk about turning on $wgSecureLogin for WMF sites, there has been a lot of misconceptions about how the option works, and difference of opinions about how they should work in the future. I started: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security It would be great to get feedback on the "Longer Term Questions" section. Also, if anyone isn't entirely clear about how the preferences work, hopefully this will provide some clarification.

14 35

Bugzilla Weekly Report
by reporter 26 Aug '13

26 Aug '13

1 0

ResourceLoader support question: how to construct a value in CSS from PHP
by Thomas Gries 26 Aug '13

26 Aug '13

The extension OpenID loads a CSS file via RL: $myResourceTemplate = array( 'localBasePath' => $path . '/skin', 'remoteExtPath' => 'OpenID/skin', 'group' => 'ext.openid', ); ... $wgResourceModules['ext.openid.icons'] = $myResourceTemplate + array( 'styles' => 'openid.css', 'dependencies' => array( 'ext.openid' ) ); openid.css comprises lines such as #openid_provider_OpenID_icon { /*@embed*/background-image: url(icons/OpenID_large.png); } Question: ========= How to contruct the background-image filename from a value in one of the OpenID PHP modules ?

5 6

Wikimedia's anti-surveillance plans: site hardening
by Zack Weinberg 26 Aug '13

26 Aug '13

Hi, I'm a grad student at CMU studying network security in general and censorship / surveillance resistance in particular. I also used to work for Mozilla, some of you may remember me in that capacity. My friend Sumana Harihareswara asked me to comment on Wikimedia's plans for hardening the encyclopedia against state surveillance. I've read the discussion to date on this subject, but it was kinda all over the map, so I thought it would be better to start a new thread. Actually I'm going to start two threads, one for general site hardening and one specifically about traffic analysis. This is the one about site hardening, which should happen first. Please note that I am subscribed to wikitech-l but not wikimedia-l (but I have read the discussion over there). The roadmap at https://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/ looks to me to have the right shape, but there are some missing things and points of confusion. The first step really must be to enable HTTPS unconditionally for everyone (whether or not logged in). I see on the roadmap that there is concern that this will lock out large groups of users, e.g. from China; a workaround simply *must* be found for this. Everything else that is worth doing is rendered ineffective if *any* application layer data is *ever* transmitted over an insecure channel. There is no point worrying about traffic analysis when an active man-in-the-middle can inject malicious JavaScript into unsecured pages, or a passive one can steal session cookies as they fly by in cleartext. As part of the engineering effort to turn on TLS for everyone, you should also provide SPDY, or whatever they're calling it these days. It's valuable not only for traffic analysis' sake, but because it offers server-side efficiency gains that (in theory anyway) should mitigate the TLS overhead somewhat. After that's done, there's a grab bag of additional security refinements that are deployable immediately or with minimal-to-moderate engineering effort. The roadmap mentions HTTP Strict Transport Security; that should definitely happen. All cookies should be tagged both Secure and HttpOnly (which renders them inaccessible to accidental HTTP loads and to page JavaScript); now would also be a good time to prune your cookie requirements, ideally to just one which does not reveal via inspection whether or not someone is logged in. You should also do Content-Security-Policy, as strict as possible. I know this can be a huge amount of development effort, but the benefits are equally huge - we don't know exactly how it was done, but there's an excellent chance CSP on the hidden service would have prevented the exploit discussed here: https://blog.torproject.org/blog/hidden-services-current-events-and-freedom… Several people raised concerns about Wikimedia's certificate authority becoming compromised (whether by traditional "hacking", social engineering, or government coercion). The best available cure for this is called "certificate pinning", which is unfortunately only doable by talking to browser vendors right now; however, I imagine they would be happy to apply pins for Wikipedia. There's been some discussion of an HSTS extension that would apply a pin (http://tools.ietf.org/html/draft-evans-palmer-key-pinning-00) and it's also theoretically doable via DANE (http://tools.ietf.org/html/rfc6698); however, AFAIK no one implements either of these things yet, and I rate it moderately likely that DANE is broken-as-specified. DANE requires DNSSEC, which is worth implementing for its own sake (it appears that the wikipedia.org. and wikimedia.org. zones are not currently signed). Perfect forward secrecy should also be considered at this stage. Folks seem to be confused about what PFS is good for. It is *complementary* to traffic analysis resistance, but it's not useless in the absence of. What it does is provide defense in depth against a server compromise by a well-heeled entity who has been logging traffic *contents*. If you don't have PFS and the server is compromised, *all* traffic going back potentially for years is decryptable, including cleartext passwords and other equally valuable info. If you do have PFS, the exposure is limited to the session rollover interval. Browsers are fairly aggressively moving away from non-PFS ciphersuites (see <https://briansmith.org/browser-ciphersuites-01.html>; all of the non-"deprecated" suites are PFS). Finally, consider paring back the set of ciphersuites accepted by your servers. Hopefully we will soon be able to ditch TLS 1.0 entirely (all of its ciphersuites have at least one serious flaw). Again, see <https://briansmith.org/browser-ciphersuites-01.html> for the current thinking from the browser side. zw

16 29

OAuth
by Chris Steipp 25 Aug '13

25 Aug '13

As mentioned earlier this week, we deployed an initial version of the OAuth extension to the test wikis yesterday. I wanted to follow up with a few more details about the extension that we deployed (although if you're just curious about OAuth in general, I recommend starting at oauth.net, or https://www.mediawiki.org/wiki/Auth_systems/OAuth): * Use it: https://www.mediawiki.org/wiki/Extension:OAuth#Using_OAuth should get you started towards using OAuth in your application. * Demo: Anomie setup a excellent initial app (I think counts as our first official, approved consumer) here https://tools.wmflabs.org/oauth-hello-world/. Feel free to try it out, so you can get a feel for the user experience as a user! * Timeline: We're hoping to get some use this week, and deploy to the rest of the WMF wikis next week if we don't encounter any issues. * Bugs: Please open bugzilla tickets for any issues you find, or enhancement requests-- https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions… And some other details for the curious: * Yes, you can use this on your own wiki right now! It's meant to be used in a single or shared environment, so the defaults will work on a standalone wiki. Input and patches are welcome, if you have any issues setting this up on your own wiki. * TLS: Since a few of you seem to care about https... The extension currently implements OAuth 1.0a, which is designed to be used without https (except to deliver the shared secret to the app owner, when the app is registered). So calls to the API don't need to use https. * Logging: All edits are tagged with the consumer's id (CID), so you can see when OAuth was used to contribute an edit. Enjoy!

9 13

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page:

2026

2025

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