Re: [Wikitech-l] jQuery UI 1.10.4 and IE6 support
Support can mean either depending on the context. Most of this is uncontroversial, but I found it useful to think through and sum up. From a platform perspective to support a browser means that the user experience is considered acceptable, tested against, and we're committed to keeping it that way (which may mean moving a browser or mediawiki feature from one Grade to another). Don't forget that there's a lot more to our platform than javascript execution! Supporting users of browsers we provide a javascript-less experience still requires a lot of things to work; such as: * Content delivery. (Can't require HTTP features that don't work, e.g. some sites require every user to be in a session with an ID and for new visitors they respond with an empty page that sets session cookies based and refreshes to display the real page, we couldn't do that if we want to support browsers without cookies or with cookies disabled.) * Enough styles for the page to be usable. (Let's say background-image were new in CSS3, then we couldn't exclusively have a design with white text on a background image without a fallback colour to ensure the text is readable without that image.) * HTML implementation. (Say a supported browser doesn't allow relative urls in a form action attribute, we'd have to make it an absolute url.) * Character encoding. (If certain unicode literals aren't interpreted properly, we may have to explicitly encode them.) * We'd commit to doing our best to keep their stuff secure (e.g. while we may patch against a browser-specific CSRF exploit for an unsupported browser out of the goodness of our hearts, we pretty much have to if it affects a supported browser). All these areas and more do in fact have problems we account for, but I think we've been at it long enough that we've got these bases covered in MediaWiki and in our web servers and caching proxies. However as we keep introducing new backend code and iterate our infrastructure, we need to ensure we don't miss anything. -- Timo On 27 Jul 2014, at 18:42, Jon Robson jdlrob...@gmail.com wrote: A few quick notes: * we should be killing jQuery ui. not upgrading it :) * progressive enhancement != supporting IE6. We should be doing this anywhere. Personally I would be fine with giving IE6,7, even 8 and maybe 9 no JavaScript whatsoever and supporting them simply from simply a css perspective. People can edit and read without JavaScript. * I think we should be careful when we say support. Does support meaning any new features we write in JavaScript have to work on these platforms or does in mean they need to be usable? I'd say the latter. It sounds like the discussion is around supporting JS.. On 24 Jul 2014 13:49, Sumana Harihareswara suma...@wikimedia.org wrote: Replying with a subject line. :) Good luck Thomas. Sumana Harihareswara Senior Technical Writer Wikimedia Foundation On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall thomasmulhall...@yahoo.com wrote: Hi should we upgrade jquery ui to version 1.10.4. even though we recently upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The main difference is it removes internet explorer 6 support which as long as internet explorer 6 users can edit and view the page it wont matter to them. here is the changelog jqueryui.com/changelog/1.10.0/ ___ 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 ___ 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] Pywikibot bug triage
Pywikibot bug triage is finished now and during the event 189 bugs were changed and 39 one of them were closed. Considering that pywikibot currently has about 450 bugs, that's quite good. A big thank you to people who joined and participated. Best On 7/3/14, Amir Ladsgroup ladsgr...@gmail.com wrote: And you can add your name in here https://www.mediawiki.org/wiki/Bug_management/Triage/20140724 Best On Thu, Jul 3, 2014 at 9:55 PM, Amir Ladsgroup ladsgr...@gmail.com wrote: Hello, There will be the next round of bug triage https://www.mediawiki.org/wiki/Bug_management/How_to_triage for pywikibot in July 24th - 27th in #pywikibot channel. We will focus on prioritizing and categorizing bugs listed here. https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibotresolution=---query_format=advanced https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibotresolution=---query_format=advanced I hope to see you there. Best https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibotresolution=---query_format=advanced -- Amir -- Amir -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Welcoming Joel Sahleen to the Language Engineering team
Hi Everyone, Please join me in welcoming Joel Sahleen as software engineer in the Language Engineering team. Joel joins us from Adobe where he has been a globalization engineer for the past 5 years. He developed the internationalization and localization system for PHP components used in the Adobe Marketing Cloud. He also helped build a continuous integration system for localization that currently supports many different products, programming languages and file formats. Prior to becoming a techie and taking the job at Adobe, Joel did a long stint as a Teaching Fellow in the Departments of East Asian Languages and Literatures and Religious Studies at Stanford University. Joel taught courses on Early Chinese Language, Thought, History and Culture and developed course materials used for Advanced Classical Chinese. Joel is very interested in the development of collaborative, online, multilingual texts and is looking forward to advance platform support for languages, scripts, encodings and formats in the Wikimedia universe. In Joel’s own words - “My main reason for wanting to join the WMF is that I believe in its mission. I believe providing access to knowledge is one of the best things you can do to help a person live up to his or her full potential, and as the world becomes more interconnected and interdependent, I believe it is essential that the pursuit of knowledge becomes more community-driven and accessible to everyone. Language engineering is key to making this collaborative effort possible and I am glad to be joining a team and an organization that is actively working to make the world a better place.” I couldn’t agree with him more. Joel lives right outside Salt Lake City, Utah with his wife, two boys, nephew and two dogs. He enjoys traveling, writing, painting and most of all - learning new things. He can be reached on email at jsahleen at wikimedia.org and on our irc channels including #mediawiki, #wikimedia-dev and #mediawiki-i18n. He will also be at Wikimania so feel free to say hello! Joel - I am excited to have you on the language engineering team :-) Welcome! - Alolita Alolita Sharma आलोलिता शर्मा Director of Engineering Internationalization Localization Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcoming Joel Sahleen to the Language Engineering team
On 28 July 2014 07:45, Alolita Sharma asha...@wikimedia.org wrote: Hi Everyone, Please join me in welcoming Joel Sahleen as software engineer in the Language Engineering team. Welcome aboard, Joel! Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] What does a hackathon cost?
Hi everyone, Different chapters are looking into organizing next years hackathon. One of the recurring questions is how much it costs to organize such an event. To make it easier to answer this question we published the budget of the Amsterdam hackathon at https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Budget . I believe it's the intention to also publish the budget of this year (Zürich) and 2012 (Berlin). That should give quite a complete overview. One note of warning: You might have different costs than we had. Take for example the internet and wireless: We didn't spend any money on that. Maarten ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New RfC: server-side Javascript error logging
I would probably recommend using the existing EventLogging infrastructure for sending the data to our back end, assuming it won't explode under heavy load spikes... Which it might. :) Eventlogging is not the best choice. Besides not handling bursts of traffic it is -currently- a tier-2 service. Any logging infrastructure should be tier-1. http://m.mediawiki.org/wiki/EventLogging/OperationalSupport On Jul 25, 2014, at 1:11 AM, Brion Vibber bvib...@wikimedia.org wrote: I would probably recommend using the existing EventLogging infrastructure for sending the data to our back end, assuming it won't explode under heavy load spikes... Which it might. :) -- Brion On Jul 24, 2014 3:14 PM, Gergo Tisza gti...@wikimedia.org wrote: Hi all, frontend development is greatly hindered by not having logs of errors that happen in production. If there is a mistake in a PHP file, it is usually quickly caught after deployment when a large number of exceptions show up in the error log. If the mistake is in a JS file, it can take a long time until the error is reported and reproduced; especially so if it only happens under exotic conditions. Many sites solve this issue by setting up an error handler in Javascript which reports any errors that occurred to a logging server. I tried to make a laundry list of things that need to be done or considered if we want to set up such logging for Wikimedia sites and/or MediaWiki in general; I put it up as a draft RfC at [1]. I would appreciate feedback on whether this is plausible or worthwhile. [1] https://www.mediawiki.org/wiki/Requests_for_comment/Server-side_Javascript_error_logging ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What does a hackathon cost?
Am 28.07.2014 18:36, schrieb Maarten Dammers: Different chapters are looking into organizing next years hackathon. One of the recurring questions is how much it costs to organize such an event. To make it easier to answer this question we published the budget of the Amsterdam hackathon at https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Budget . I believe it's the intention to also publish the budget of this year (Zürich) and 2012 (Berlin). That should give quite a complete overview. I just did that: https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Budget Please take the figures with a grain of salt. Not all WMF scholarship receipts have been handed in yet, so those numbers are not accurate. Also there have been some re-arrangements of costs between entities offering scholarship and what was a scholarship or a business travel. But the Youth Hostel bill (and that is the main part) has been settled already. There were obviously further costs not covered in this budget: Hotel accommodation not booked through us. I know that WMF and WMDE had a bunch of people in some hotels. These costs are NOT included. Also we do not know the reimbursed travel costs by other chapters - we just got the cost estimates in the scholarship applications and later invoiced the accommodation to them. A note for the Wifi: We had planned to get a sponsor for our own Wifi hardware we could re-use in other events. Our search for sponsors was unsuccessful - too late, as we learned, six months is for most companies NOT ENOUGH! Apply for sponsorships BEFORE SUMMER, at least in Switzerland. So I bought Wifi gear by myself (as a private person with a freelance business) and rented it to WMCH for 10 EUR / day per device and 25 EUR / day for the server. The switch I already owned was included for free. This obviously didn't make up for the investment (~2.500 EUR) and the equipment is meant to be re-used. I just bought a big box for it and shipped everything to London, for Wikimania. https://www.facebook.com/x80686/posts/321911134652244 If you need it, let me know. When the return of investment is reached I am also happy to rent it for free. /Manuel -- Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 34066-22 - www.wikimedia.ch ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Language Extension Bundle 2014.07 release
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.07. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.22.x releases.
* Download:
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.07.tar.bz2
* sha256sum: 8af5c001db9375bf8dfd16495c7a88fc8dc9b4fe281b1048f6bea6c490bc4a9d
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CleanChanges and LocalisationUpdate ==
* Only localisation updates
== CLDR ==
* Localisation updates.
* Updated to CLDR 25 and fixed rebuild script.
* Added Simple English translation to Persian.
== Translate ==
=== Noteworthy changes ===
* Bug 67921: Store translatable page translation units in variable
form to improve translation memory suggestions.
* Display source language for the pages in Special:Translate
* Fixed ElasticSearchTTMServer to not return matches for single word
messages only.
* Changes in Special:PageMigration:
** Bug 66162: Simplistic alignment based on h2 headers.
** Bug 65942: Split headers from other wiki text in translation units.
** Added script for preparing the page for Translation.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Stopped using deprecated jquery.json module, this will make ULS
slightly smaller.
* Added support for Rutul language.
=== Input Methods ===
* Added Ludic (lud) transliteration layout.
* Added Tibetian (bo) EWTS layout.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
tl;dr: I am going to break your workflow and your wiki. Skip to the last section and read on. == Background == As you know, I've been working on a GSoC project to better separate skins and core MediaWiki [1]. Moving Vector and MonoBook to separate repositories is the final step of it, and it's exactly as scary as it sounds. Until recently MediaWiki was heavily interconnected with the core skins, particularly Vector – right now it is only slightly interconnected and I have some patches pending to make it not so at all [2]. [1] https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki [2] https://gerrit.wikimedia.org/r/#/q/topic:skinning,n,z == The plan == * Fix up some remaining issues with Vector being required (I have already fixed most) * Stop always loading MonoBook and Vector [patch pending: https://gerrit.wikimedia.org/r/148509 + dependencies] * Use a special fallback when no skins are installed [patch pending: https://gerrit.wikimedia.org/r/148508] * Move MonoBook and Vector to separate repositories * Ship MonoBook, Vector and some more skins with the installer tarball * Enable them during the installation [patch merged: https://gerrit.wikimedia.org/r/138652] == What it means for you == If you're upgrading a wiki or you're a developer working on master, THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to work, it will just look ugly (no styles). When we do this and you upgrade, you're going to get a big helpful message asking you to install and enable some skins and explaining how to do this (see https://gerrit.wikimedia.org/r/148508 for implementation; basically, put the files/repository under skins/ and require_once in LocalSettings). Try it out with this patch: https://gerrit.wikimedia.org/r/148509 After you do this, you'll be able to switch to slightly older MediaWiki versions without things breaking, as the new skins will work with old MediaWiki (the new directory names are different… unless you're using a case-insensitive OS). I hope this sounds reasonable to everyone, and I hope to have this done around the time of Wikimania (possibly during it; I'll be there). I don't think there is a less disruptive way to do this, other than not doing it at all; if you come up with one, please share it. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki now supports PBKDF2 and Bcrypt
Hi everybody, I was on the brink of celebrating the one-year anniversary of a patch I submitted being open, but today it was finally merged! https://gerrit.wikimedia.org/r/77645 The old User::comparePasswords() and User::crypt() functions have been replaced with a new password hashing API. This means MediaWiki now natively supports Bcrypt and PBKDF2 as replacement password hashing algorithms. Furthermore, the system allows seamless transitioning, meaning users’ password hashes will be updated automatically the next time they log in. This means that MD5 is almost out the door, which is a big win (a follow up patch, https://gerrit.wikimedia.org/r/149658, changes the default to PBKDF2, which would mean any wiki that upgrades to 1.24 would automatically switch away from MD5). I’d like to thank Aaron Schulz, Chris Steipp, Krinkle, and many others who helped get this through. -- Tyler Romeo 0x405D34A7C86B42DF ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Hi Bartosz, Sounds good. Bartosz Dziewoński schreef op 28-7-2014 20:53: If you're upgrading a wiki or you're a developer working on master, THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to work, it will just look ugly (no styles). And I assume whatever MediaWiki version this will be packaged into should will include an upgrade script for people who just bump one version? Maarten ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Why not just move them to an extension? moving them to their own repo begs for a headaches On Mon, Jul 28, 2014 at 4:50 PM, Maarten Dammers maar...@mdammers.nl wrote: Hi Bartosz, Sounds good. Bartosz Dziewoński schreef op 28-7-2014 20:53: If you're upgrading a wiki or you're a developer working on master, THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to work, it will just look ugly (no styles). And I assume whatever MediaWiki version this will be packaged into should will include an upgrade script for people who just bump one version? Maarten ___ 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] MediaWiki now supports PBKDF2 and Bcrypt
Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in the security community about which is better so my comment isn't intended as criticism. I'm just interested in the thinking behind this decision. Thanks, Pine On Jul 28, 2014 1:35 PM, Tyler Romeo tylerro...@gmail.com wrote: Hi everybody, I was on the brink of celebrating the one-year anniversary of a patch I submitted being open, but today it was finally merged! https://gerrit.wikimedia.org/r/77645 The old User::comparePasswords() and User::crypt() functions have been replaced with a new password hashing API. This means MediaWiki now natively supports Bcrypt and PBKDF2 as replacement password hashing algorithms. Furthermore, the system allows seamless transitioning, meaning users’ password hashes will be updated automatically the next time they log in. This means that MD5 is almost out the door, which is a big win (a follow up patch, https://gerrit.wikimedia.org/r/149658, changes the default to PBKDF2, which would mean any wiki that upgrades to 1.24 would automatically switch away from MD5). I’d like to thank Aaron Schulz, Chris Steipp, Krinkle, and many others who helped get this through. -- Tyler Romeo 0x405D34A7C86B42DF ___ 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] Moving Vector and MonoBook to separate repositories and what it means for you
On Mon, 28 Jul 2014 22:50:49 +0200, Maarten Dammers maar...@mdammers.nl wrote: And I assume whatever MediaWiki version this will be packaged into should will include an upgrade script for people who just bump one version? There is no need for an upgrade script. If you're upgrading using the tarball, then all you need to do is copy a few lines of code from the warning message and paste them into LocalSettings.php. It looks like this: http://i.imgur.com/A6rOOFZ.png (I have a few custom skins installed in this example). (The code for this is not merged yet, comments welcome at https://gerrit.wikimedia.org/r/148508.) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverr...@gmail.com wrote: Why not just move them to an extension? moving them to their own repo begs for a headaches I don't understand the problem you see here nor the solution you're proposing. Elaborate? -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
I use a standard git checkout. Moving these to their own separate location is going to be a pain in the ass. If the skins are moved to the existing extension system it causes far fewer problems and does not introduce additional steps in upgrading/maintaining a site. When we start having sub repos and forking left and right it gets ugly. We already have an existing framework for adding modules to mediawiki (Extensions) let's use that vs re-inventing the wheel. On Monday, July 28, 2014, Bartosz Dziewoński matma@gmail.com wrote: On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverr...@gmail.com wrote: Why not just move them to an extension? moving them to their own repo begs for a headaches I don't understand the problem you see here nor the solution you're proposing. Elaborate? -- Matma Rex ___ 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
[Wikitech-l] MediaWiki third-party release managers
I am pleased to announce (after far too long of a delay, my apologies), that Mark Hershberger and Markus Glaser will take on the task of managing the third-party releases of MediaWiki for another year. Congrats Mark and Markus! I'd like to explicitly thank the International Consortium team for their proposal. The choice was indeed a hard one to make and I'm glad we had the second proposal to add context and perspective to Mark's and Markus's. There will be a few changes to this work this coming year, mostly in terms of transparency. Mark and Markus have agreed to conduct quarterly reviews for their work and the output of those meetings will be publicly shared. That means you'll (soon) be able to see the quarterly goals and their progress. Also, we hope to see more collaboration between Mark and Markus and the wider community in the supportive work; the work that everyone can help with to make the releases as good as they can be. We'll be monitoring this collaboration in review process over the course of the year and we currently plan to call out collaboration goals in next year's call for proposals. I look forward to another year of working with Mark and Markus! Best, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki now supports PBKDF2 and Bcrypt
On Mon, Jul 28, 2014 at 5:24 PM, Pine W wiki.p...@gmail.com wrote: Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in the security community about which is better so my comment isn't intended as criticism. I'm just interested in the thinking behind this decision. It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as does PBKDF2, whereas scrypt requires an extension. It should be noted, however, that the patch that was merged implements an extensible password API, so it would be trivial to implement scrypt support if we wanted to. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki now supports PBKDF2 and Bcrypt
- Original Message - From: Tyler Romeo tylerro...@gmail.com It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as does PBKDF2, whereas scrypt requires an extension. It should be noted, however, that the patch that was merged implements an extensible password API, so it would be trivial to implement scrypt support if we wanted to. Yup: figure out what general case your particular problem is a special case of, and then implement the general case. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
