This is a notice that on Thursday, November 14th between 21:00-22:00 UTC
(1-2pm PST) Wikimedia Foundation will release security updates for current
and supported branches of the MediaWiki software, as well as several
extensions. Downloads and patches will be available at that time.
Hello,
A quick reminder that the Wikimedia Language Engineering team will be
hosting an IRC office hour from 1500 to 1600UTC later today on
#wikimedia-office (FreeNode). Please see below for the event details.
Thanks
Runa
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Thu, Nov 7, 2013 at 11:40 AM
Subject: Language Engineering IRC Office Hour on November 13, 2013 at 1500
UTC
To: MediaWiki internationalisation <mediawiki-i18n(a)lists.wikimedia.org>,
Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>, Wikimedia
developers <wikitech-l(a)lists.wikimedia.org>,
wikitech-ambassadors(a)lists.wikimedia.org
[x-posted]
Hello,
The Wikimedia Language Engineering team will be hosting an IRC office
hour on Wednesday, November 13, 2013 between 15:00 - 16:00 UTC on
#wikimedia-office. (See below for timezone conversion and other details.)
We will be talking about some of our recent and upcoming projects and then
taking questions for the remaining time.
We also look forward to hear about anything that needs our attention.
Questions and other concerns can also be sent to me directly before the
event. See you there!
Thanks
Runa
=== Event Details ===
What: WMF Language Engineering Office hour
When: November 13, 2013 (Wednesday). 1500-1600 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131113T1500
Where: IRC Channel #wikimedia-office on FreeNode
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
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
The 1.22 release adds a new configuration variable,
$wgRedactedFunctionArguments, that allows administrators of MediaWiki
installations to designate function arguments that should be redacted
from stack traces. For example:
$wgRedactedFunctionArguments[] = array('User::comparePasswords' =>
array( 0, 1 ) )
This value specifies that whenever the method User::comparePasswords
appears in an exception stack trace, the value of the first and second
arguments are to be redacted, meaning the string 'REDACTED' is
inserted where the argument value would otherwise appear. The case for
this feature was made in
<https://bugzilla.wikimedia.org/show_bug.cgi?id=30714>.
I think that it is a design blunder, and that we should remove it from
MediaWiki. The task of making $wgRedactedFunctionArguments
comprehensive is hopelessly gargantuan. It would require something
like a full trace of the flow of data throughout all of MediaWiki and
its extensions.
The best case scenario is that the feature is not used. The worst case
-- which seems to be materializing, judging by the default value
assigned to it in DefaultSettings.php -- is that it is used with a
short and chronically out-of-date list of obvious suspects, and that
the resultant traces leak private data. This is actually worse than
making no attempt at all to sanitize traces, because it is liable to
mislead and inspire false feelings of confidence.
I think that the proper way to handle low-level operational data like
stack traces is to make it clear that it is liable to contain
sensitive information, and to make no pretense at all of sanitizing
it. If there is a credible need for outputting redacted traces, the
output should exclude *all* values, not just the ones that someone
remembered to configure.
---
"Base access decisions on permission rather than exclusion. This
principle...means that the default situation is lack of access, and
the protection scheme identifies conditions under which access is
permitted. The alternative, in which mechanisms attempt to identify
conditions under which access should be refused, presents the wrong
psychological base for secure system design. A conservative design
must be based on arguments why objects should be accessible, rather
than why they should not. In a large system some objects will be
inadequately considered, so a default of lack of permission is safer.
A design or implementation mistake in a mechanism that gives explicit
permission tends to fail by refusing permission, a safe situation,
since it will be quickly detected. On the other hand, a design or
implementation mistake in a mechanism that explicitly excludes access
tends to fail by allowing access, a failure which may go unnoticed in
normal use. This principle applies both to the outward appearance of
the protection mechanism and to its underlying implementation."
("The Protection of Information in Computer Systems",
http://web.mit.edu/Saltzer/www/publications/protection/Basic.html)
---
Ori Livneh
ori(a)wikimedia.org
Hallo,
Several updates were made recently in the UniversalLanguageSelector
extension to improve its performance. This means that if you use any of the
ULS facilities in your extensions or gadgets, such as web fonts, IMEs,
language data functions like getDir and getAutonym, etc., you need to
ensure that the modules you need are loaded before you use their functions.
We wrote some documentation that explains how to do the fixes:
https://www.mediawiki.org/wiki/Universal_Language_Selector/Developing_with_…
We are aware of ULS usage in Wikibase and VisualEditor, and we could use
assistance from the Wikidata and VE developers in discussing, reviewing and
testing the changes. It is also used in the Translate and TwnMainPage
extensions, which we have fixed ourselves.
Particularly important updates are:
* https://gerrit.wikimedia.org/r/#/c/93926 , which makes the extension
lazy-load some of its functional ResourceLoader modules to make the initial
page loading lighter.
* https://gerrit.wikimedia.org/r/#/c/94116 , which lazy-loads the uls.data
module - language info database and related functions.
Please contact us here or on IRC ( #mediawiki, #mediawiki-i18n ) if you
have any questions.
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hello,
in the current version of ubuntu (13.10) you can compile pages from
MediaWiki to LaTeX using the commands:
sudo apt-get install mediawiki2latex
mediawiki2latex -u https://en.wikipedia.org/wiki/Adam_Ries -o AdamRies.pdf
Yours Dirk
Hi,
would anyone experienced (like hashar) be interested in setup of
jekins on wikimedia labs so that we can get a unit test environment
available to all devs for any projects, written in languages like:
* C
* C++
* Python
* PHP
+ other frequently used languages
I think it would be useful for some (at least me) people :)