Re: [Wikitech-l] New password hashing proposal
On Thu, Aug 19, 2010 at 5:20 PM, Tim Starling tstarl...@wikimedia.org wrote: In a past life, I was a PhD student working on a broad military-funded project which aimed to break all known asymmetric cryptography schemes using large, expensive machines known as quantum computers. There will come a point, maybe even this century, when large-block symmetric ciphers like the WHIRLPOOL compression function will be the only sort of security we will have left, unless you don't mind the government being able to read all your messages. Asymmetric ciphers are the only kind of widely-used cipher that have a known vulnerability which allows cryptanalysis exponentially faster than brute force, i.e. in polynomial time and space with respect to the key length. So I think your faith is misplaced. You must have missed the recent news. At least one obscure asymmetric cipher is provably immune to all known quantum computing attacks: http://www.technologyreview.com/blog/arxiv/25629/ -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New password hashing proposal
Ryan Lane wrote: http://newsarse.com/2010/08/13/if-you-can-remember-your-password-then-its-hopelessly-inadequate-warn-researchers/ Passwords suck, and people are a problem. Now, if we could distribute RSA fobs to every editor ... We could do a less secure, but more-secure-than-passwords alternative, which is to use email or SMS as a one time password device. SMS is obviously more secure than email, but would require us to ask people for their phone numbers. We could also make a PKI infrastructure, and allow certificate login, which is obviously safer than passwords. The real problem with any system stronger than passwords, is that it requires a level of complexity that would be difficult for us, and either annoying or very confusing for users. Respectfully, Ryan Lane OpenID? The account my own OpenID is tied to has two-factor authentication. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fixme, please fix me!
Just a friendly reminder to everyone about their outstanding FIXMEs in Code Review (up to 97[1] from 63[2] beginning of June). The following is a list of everyone who has a commit with a fixme on it: tparscal - 11 awjrichards - 7 peter17 - 6 nimishg - 5 werdna - 4 catrope - 4 platonides - 4 demon - 4 huji - 4 kaldari - 4 siebrand - 2 jeroendedauw - 2 tstarling - 2 happy-melon - 2 sean_colombo - 2 papyromancer - 2 btongminh - 2 pdhanda - 2 neilk - 2 daniel - 2 maxsem - 2 tisane - 1 dale - 1 vyznev - 1 freakolowsky - 1 soxred93 - 1 nikerabbit - 1 mah - 1 brion - 1 aaron - 1 hartman - 1 diana - 1 dantman - 1 svip - 1 ialex - 1 leonsp - 1 philip - 1 vibber - 1 jdpond - 1 yaauie - 1 purodha - 1 rainman - 1 mgrabovsky - 1 TOTAL: 97 Please be sure to ping anyone you know isn't on this mailing list (like some contractors, or people working on special projects maybe?) so we can get everyone informed. Cheers! Siebrand [1] http://www.mediawiki.org/w/index.php?limit=100title=Special%3ACode%2FMediaWiki%2Fstatus%2Ffixme [2] http://lists.wikimedia.org/pipermail/wikitech-l/2010-June/048066.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New password hashing proposal
Aryeh Gregor Simetrical+wikilist at gmail.com writes: I don't think so. I think it's completely reasonable, when talking about Wikipedia. Hackers go after money, and there's no money in hacking Wikipedia. We have nothing secret or valuable that's not already readily available. We have no black-market competitors who want to try disrupting our service. Any malicious action could be easily reversed. The worst we have to worry about is someone with a grudge trying to frame someone else, which has happened, but it's hardly a pressing concern. That is true for regular accounts, but with administrator access you can run malicious javascript on a large number of machines or track the visitors of a certain article. A totalitarian government going after checkuser access is not an unimaginable scenario either. That said, the two things that would make the most difference (and are also much easier to implement) are SSL and password strength requirements. There is no point in fancy stuff like SMS or asymmetric cyphers which would be much more disruptive, a lot harder to introduce, and would have less effect. When few enough people want a preference that more people are likely to turn it on by mistake than deliberately, and when there's significant harm or confusion from turning it on by mistake, that's a sign that it's a bad preference. (See also: Use external editor.) Not to disagree with your general point, but that specific problem would be easy to handle by throwing a dialog with big red exclamation marks saying WARNING! Arey you REALLY sure you know what you are doing? when one is about to turn on such a feature. (Or only showing the controls when the user selects expert mode.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Alternative authentication methods (was New password hashing proposal)
When few enough people want a preference that more people are likely to turn it on by mistake than deliberately, and when there's significant harm or confusion from turning it on by mistake, that's a sign that it's a bad preference. (See also: Use external editor.) Not to disagree with your general point, but that specific problem would be easy to handle by throwing a dialog with big red exclamation marks saying WARNING! Arey you REALLY sure you know what you are doing? when one is about to turn on such a feature. (Or only showing the controls when the user selects expert mode.) It would be fairly difficult to lock yourself out just by enabling the option, as part of enabling the option would be to login with the new authentication method. The biggest issue would be reseting credentials when the what you have is lost. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Error installing CentralAuth
Hello, I hope somebody can help me, I'm trying to install CentralAuth on my wikifarm but I get a strange error and I don't know what I'm missing... My testsetup contains 4 databases so I made the conf: $wgLocalDatabases = array( 'wikiweet', 'llamada_intern', 'wikiweet_intern', 'llamada', 'wikiweet_recepten', ); $wgConf-wikis = $wgLocalDatabases; $wgConf-suffixes = $wgLocalDatabases; $wgConf-siteParamsCallback = 'efGetSiteParams'; $wgConf-extractAllGlobals( $wgDBname ); the last lines of my localsettings.php are; require_once (/home/CentralAuth/CentralAuth.php); $wgCentralAuthDatabase = 'shared'; When I try to run: migratePass0.phphttp://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/CentralAuth/migratePass0.phpor migratePass1.phphttp://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/CentralAuth/migratePass0.php I get this error: CentralAuth migration pass 1: Finding accounts which can be migrated without interaction... Er is een syntaxisfout in het databaseverzoek opgetreden. Het laatste verzoek aan de database was: âSELECT user_id,user_email,user_email_authenticated,user_password,user_editcount FROM `user` WHERE user_name = 'A verspuy' LIMIT 1 â CentralAuthUser::localUserDataâ De database gaf de volgende foutmelding: â1146: Table 'wikiweet.user' doesn't exist (localhost)â When I try to use special:MergeAccount I also got the error that Table wikiweet.user doesn't exist All databases are localhost, and have the prefix mw_ and I'm sure all databases contain a user table. I run the trunk version of mediawiki. Can somebody give advice? -- Regards, Huib Abigor Laurens Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New password hashing proposal
On Thu, Aug 19, 2010 at 8:20 PM, Tim Starling tstarl...@wikimedia.org wrote: In a past life, I was a PhD student working on a broad military-funded project which aimed to break all known asymmetric cryptography schemes using large, expensive machines known as quantum computers. There are more than a few asymmetric cryptography schemes that aren't known to be breakable by quantum computer. The popular ones (RSA, Diffie-Hellman) are all known to be breakable, though. On Thu, Aug 19, 2010 at 11:06 PM, Tim Starling tstarl...@wikimedia.org wrote: Well, a GPU is fast because it is massively parallel, with hundreds of cores. Each core is typically slower than a CPU. I chose a function which is non-parallelisable, so you'd expect computation of a single hash to be slower on a GPU than on a CPU. But a GPU can calculate hundreds of them at a time. Yeah, and attackers don't care about latency. They care about throughput. On Fri, Aug 20, 2010 at 8:16 AM, Tgr gti...@gmail.com wrote: That is true for regular accounts, but with administrator access you can run malicious javascript on a large number of machines or track the visitors of a certain article. Correct. As I said, we should absolutely be requiring secure passwords for admins on all projects. Upon promotion, the user should be required to re-enter their password before they get access to elevated privileges, and change it if it's not secure enough. A totalitarian government going after checkuser access is not an unimaginable scenario either. We're unlikely to be able to foil a totalitarian government of any size. They can do things like intercept any connections to the site, providing a forged certificate for HTTPS via a CA they control, and steal passwords or cookies. They might even be able to reroute arbitrary traffic through their borders by serving false BGP information or something (I don't know enough about that to say). But they probably don't care that much about all of this, because they don't actually need things like evidence to bash down your door and execute you for treason. That said, the two things that would make the most difference (and are also much easier to implement) are SSL and password strength requirements. There is no point in fancy stuff like SMS or asymmetric cyphers which would be much more disruptive, a lot harder to introduce, and would have less effect. We should definitely have HTTPS forced on for logins. And we should definitely have password strength requirements for admins. Not to disagree with your general point, but that specific problem would be easy to handle by throwing a dialog with big red exclamation marks saying WARNING! Arey you REALLY sure you know what you are doing? when one is about to turn on such a feature. (Or only showing the controls when the user selects expert mode.) Are you sure? dialogs are terrible UI. Users will often click through without reading them, or cancel without reading them, or read them and not understand them, or click the wrong button by mistake. Plus they're really annoying, since they interrupt what you were trying to do. It makes much more sense to remove the option and let people use the API or custom JavaScript or a browser extension if they want to use an external editor. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fixme, please fix me!
Can we please exclude branches from this calculation? - Trevor On 8/20/10 3:54 AM, Siebrand Mazeland wrote: Just a friendly reminder to everyone about their outstanding FIXMEs in Code Review (up to 97[1] from 63[2] beginning of June). The following is a list of everyone who has a commit with a fixme on it: tparscal - 11 awjrichards - 7 peter17 - 6 nimishg - 5 werdna - 4 catrope - 4 platonides - 4 demon - 4 huji - 4 kaldari - 4 siebrand - 2 jeroendedauw - 2 tstarling - 2 happy-melon - 2 sean_colombo - 2 papyromancer - 2 btongminh - 2 pdhanda - 2 neilk - 2 daniel - 2 maxsem - 2 tisane - 1 dale - 1 vyznev - 1 freakolowsky - 1 soxred93 - 1 nikerabbit - 1 mah - 1 brion - 1 aaron - 1 hartman - 1 diana - 1 dantman - 1 svip - 1 ialex - 1 leonsp - 1 philip - 1 vibber - 1 jdpond - 1 yaauie - 1 purodha - 1 rainman - 1 mgrabovsky - 1 TOTAL: 97 Please be sure to ping anyone you know isn't on this mailing list (like some contractors, or people working on special projects maybe?) so we can get everyone informed. Cheers! Siebrand [1] http://www.mediawiki.org/w/index.php?limit=100title=Special%3ACode%2FMediaWiki%2Fstatus%2Ffixme [2] http://lists.wikimedia.org/pipermail/wikitech-l/2010-June/048066.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New password hashing proposal
-Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Tim Starling Sent: 19 August 2010 07:37 To: wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] New password hashing proposal It's been said (e.g. [1]) that hashing passwords with two rounds of MD5 is basically a waste of time these days, because brute-forcing even relatively long passwords is now feasible with cheap hardware. Indeed, you can buy software [2] which claims to be able to check 90 million MediaWiki passwords per second on an ordinary GPU. That would let you crack a random 8-letter password in 20 minutes. So the time has probably come for us to come up with a C type password hashing scheme, to replace the B-type hashes that we use at the moment. I've been thinking along the lines of the following goals: 1. Future-proof: should be adaptable to faster hardware. 2. Upgradeable: it should be possible to compute the C-type hash from the B-type hash, to allow upgrades without bothering users. 3. Efficient in PHP, with default configure options. 4. MediaWiki-specific, so that generic software can't be used to crack our hashes. The problem with the standard key strengthening algorithms, e.g. PBKDF1, is that they are not efficient in PHP. We don't want a C implementation of our scheme to be orders of magnitude faster than our PHP implementation, because that would allow brute-forcing to be more feasible than is necessary. The idea I came up with is to hash the output of str_repeat(). This increases the number of rounds of the compression function, while avoiding tight loops in PHP code. PHP's hash extension has been available by default since PHP 5.1.2, and we can always fall back to using B-type hashes if it's explicitly disabled. The WHIRLPOOL hash is supported. It has no patent or copyright restrictions so it's not going to be yanked out of Debian or PHP for legal reasons. It has a 512-bit block size, the largest of any hash function available in PHP, and its security goals state that it can be truncated without compromising its properties. My proposed hash function is a B-type MD5 salted hash, which is then further hashed with a configurable number of invocations of WHIRLPOOL, with a 256-bit substring taken from a MediaWiki-specific location. The input to each WHIRLPOOL operation is expanded by a factor of 100 with str_repeat(). The number of WHIRLPOOL iterations is specified in the output string as a base-2 logarithm (whimsically padded out to 3 decimal digits to allow for future universe-sized computers). This number can be upgraded by taking the hash part of the output and applying more rounds to it. A count of 2^7 = 128 gives a time of 55ms on my laptop, and 12ms on one of our servers, so a reasonable default is probably 2^6 or 2^7. Demo code: http://p.defau.lt/?udYa5CYhHFrgk4SBFiTpGA Typical output: :C:007:187aabf399e25aa1:9441ccffe8f1afd8c277f4d914ce03c6fcfe15 7457596709d846ff832022b037 -- Tim Starling [1] http://www.theregister.co.uk/2010/08/16/password_security_analysis/ [2] http://www.insidepro.com/eng/egb.shtml PHP's crypt has been upgraded in recent times to now include Ulrich Dreppers' SHA crypt [1] Certainly mets 1 3. [1] http://www.akkadia.org/drepper/SHA-crypt.txt Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An invitation for GSoC students
Hey, Great idea! I've written a blog post [0] outlining what I did during GSoC, the current state of the project, and what I think are the next steps. You can use this, and I'd be happy to adapt it to fit the requirements for a The Signpost message if does not already do so. I'll also be updating the documentation on MediaWiki.org in the coming days, so you might want to wait until that's done. [0] http://blog.bn2vs.com/2010/08/20/end-of-google-summer-of-code-2010/ Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- On 16 August 2010 20:41, Jarry 1250 jarry1...@gmail.com wrote: Hey all. This message is primarily directed at those students involved with this year's MediaWiki Google Summer of Code projects. Firstly, I hope this email finds you and your projects well. As I recall, the development phase is just ending, and, now that you have a little more time, it would be great to give your projects some publicity in front of a wider Wikimedia audience (all the projects appear to be applicable to at least some WMF sites; forgive me if I'm wrong). I write for *The Signpost* (its weekly Technology Report e.g. today's [1]). If you're not familiar with it, it has a fairly sizeable readership, particularly on the English Wikipedia. I'm confident many of the Tech Report readers would be intrigued to know what you've been doing, how much success you've had, and what it might mean for Wikimedia sites, as explained in your own words (just a couple of paragraphs and a thumbnail where applicable would be more than enough). If you're interested, and I hope you will be, you can either reply directly to the list, to me, or get me via my English Wikipedia talk page. Thanks, Jarry1250 p.s. I have okayed this with RobLa. [1] http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2010-08-16/Technology_report ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
Hi. Does anybody know which extension Wikia uses currently? On Wikia's SVN I've found the RTE extension[1], but I think they at least something extra for adding categories... BTW. I think that usability might consider working from their version rather then developing everything from scratch. Wikia's editor seems to work quite well for most basic pages and doesn't seem to clutter code with unwanted tags. After some tests I can certainly say it's much better then the official version of FCKeditor extension [2]. [1] https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ [2] http://www.mediawiki.org/wiki/Extension:FCKeditor_(Official) Regards, Nux. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Vector skin failures on mobile phones - any timeframe for a fix?
Brion Vibber wrote: However, we can't just use a User-Agent check in PHP for this, since 90-something percent of the time the PHP scripts are not being executed: the Squid caches respond to most web requests directly. So what would be required would be some filtering in the caches to check for particular User-Agents or other settings and send them the redirect directly, or send them through to PHP for possible redirection. (Assuming there's no problem with downstream caching, which I think should usually be ok the way we have things marked -- as long as the redirect responses are marked as private-cache or uncacheable.) A JavaScript hack was quicker to put in place than the cache-level logic, but it was only ever meant as a stopgap. -- brion vibber (brion @ pobox.com) I was precisely thinking on this the other day. The javascript is just doing a regex on the user agent, and squid is perfectly capable of doing that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
Category stuff is a separate extension independent of the RTE. https://svn.wikia-code.com/wikia/trunk/extensions/wikia/CategorySelect/ Their RTE is an improvement, but last I checked it still has enough annoying faults to have a number of wikia request it be disabled wiki-wide. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Maciej Jaros wrote: Hi. Does anybody know which extension Wikia uses currently? On Wikia's SVN I've found the RTE extension[1], but I think they at least something extra for adding categories... BTW. I think that usability might consider working from their version rather then developing everything from scratch. Wikia's editor seems to work quite well for most basic pages and doesn't seem to clutter code with unwanted tags. After some tests I can certainly say it's much better then the official version of FCKeditor extension [2]. [1] https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ [2] http://www.mediawiki.org/wiki/Extension:FCKeditor_(Official) Regards, Nux. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Vector skin failures on mobile phones - any timeframe for a fix?
yup, its seem fairly doable and the issue has been raised to our ops team. we're waiting to hear back about what's necessary in order to make it work. --tomasz On Aug 20, 2010, at 3:59 PM, Platonides wrote: Brion Vibber wrote: However, we can't just use a User-Agent check in PHP for this, since 90-something percent of the time the PHP scripts are not being executed: the Squid caches respond to most web requests directly. So what would be required would be some filtering in the caches to check for particular User-Agents or other settings and send them the redirect directly, or send them through to PHP for possible redirection. (Assuming there's no problem with downstream caching, which I think should usually be ok the way we have things marked -- as long as the redirect responses are marked as private-cache or uncacheable.) A JavaScript hack was quicker to put in place than the cache-level logic, but it was only ever meant as a stopgap. -- brion vibber (brion @ pobox.com) I was precisely thinking on this the other day. The javascript is just doing a regex on the user agent, and squid is perfectly capable of doing that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
On 8/20/10 12:57 PM, Maciej Jaros wrote: Hi. Does anybody know which extension Wikia uses currently? On Wikia's SVN I've found the RTE extension[1], but I think they at least something extra for adding categories... Not really sure, but I know what you mean. BTW, I am working on something similar, but only as a sort of sideline to my work on Multimedia Usability. Not really ready for prime time yet. HotCats is still the most featureful and most compatible with various use cases (such as category editing). BTW. I think that usability might consider working from their version rather then developing everything from scratch. Wikia's editor seems to work quite well for most basic pages and doesn't seem to clutter code with unwanted tags. After some tests I can certainly say it's much better then the official version of FCKeditor extension [2]. At the WMF, we just met with Wikia on Monday about how we can move forward together on the whole WYSIWYG front. Wikia does have a lot of nice GUI features and they say they've ironed out most of their dirty diff issues. Nevertheless they only have part of an engineer's time dedicated to editing issues[1]. So one way or another, it's going to be the MediaWiki community that takes WYSIWYG forward. The question is whether Wikia's editor is a good basis for progress on Wikimedia projects. We're trying to figure that out right now. Anyway, we're going to be talking with Wikia on a more regular basis in the future, no matter what. [1] My impression is that Wikia is really more about building on *top* of the MediaWiki platform. (They said as much in that meeting). Their main business is hosting thousands and thousands of wikis, building features that are amusing or engaging to their audience, adapting the software for advertising and commercial entities, and so on. -- Neil Kandalgaonkar |) ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fixme, please fix me!
Trevor Parscal wrote: Can we please exclude branches from this calculation? I think this is what you want. mysql select cr_author, count(*) from code_rev where cr_status = 'fixme' and cr_path not like '/branches/%' group by cr_author order by count(*) desc; +--+--+ | cr_author| count(*) | +--+--+ | awjrichards |7 | | kaldari |5 | | nimishg |5 | | werdna |4 | | platonides |4 | | huji |4 | | catrope |3 | | demon|3 | | btongminh|3 | | daniel |2 | | pdhanda |2 | | sean_colombo |2 | | happy-melon |2 | | tparscal |2 | | jeroendedauw |2 | | maxsem |2 | | mgrabovsky |1 | | rainman |1 | | yaauie |1 | | philip |1 | | hartman |1 | | ialex|1 | | mah |1 | | aaron|1 | | soxred93 |1 | | vyznev |1 | | jdpond |1 | | leonsp |1 | | tisane |1 | | thomasv |1 | | brion|1 | | nikerabbit |1 | | siebrand |1 | | tstarling|1 | | diana|1 | | dantman |1 | | purodha |1 | | svip |1 | +--+--+ 38 rows in set (0.07 sec) The total is 74. This chart could be made dynamic in a Toolserver tool, if there were interest. It could also possibly go into the extension, but the database would need some indices first. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
