There's been some comments on some old tasks such as T27707
<https://phabricator.wikimedia.org/T27707> about problems with uploading
files that include text metadata that looks like HTML elements.
Years ago, we added security checks for IE 5/6/7 to work around IE's mime
type sniffing: if you went to view a .png file directly in IE (as opposed
to in an <img>) the browser would check the first few bytes of the file to
detect its type, overriding the HTTP Content-Type header. HTML would be
detected with a higher priority than the actual image formats, making it
possible to create an actual .png image which when viewed as an image
looked like an image, but when viewed as a web page was interpreted as
HTML, including any embedded JavaScript.
(This was defense in depth in addition to hosting files on a separate
domain; among other things, we sometimes serve files out from the main
domain when dealing with archived (deleted) versions, and third-party
installs are not guaranteed to have a second domain.)
Browsers have moved on, but the code remains and it trips up legitimate
files containing links in metadata, or sometimes just random compressed
data that looks like an element!
I've done a quick research check on feasibility:
* IE 6 and earlier can no longer access Wikimedia sites due to lack of SNI
and TLS 1.0 or later
* IE 7 on Windows XP can no longer access Wikimedia sites due to lack of SNI
* IE 7 on Windows Vista **can** access Wikimedia sites.
* IE 8 and higher support X-Content-Options: nosniff to disable sniffing,
which we already use on all MediaWiki requests.
At some point Microsoft dropped the sniffing, but I'm not sure if it was a
later IE version or an Edge version. No other browsers in reasonably
current versions seem to have this problem.
So the only remaining browser version that might be affected is IE 7 on
Windows Vista, which supports SNI and TLS 1.0. It might or might not still
work once we drop TLS 1.0 some time in the future. (Per our TLS dashboard
<https://grafana.wikimedia.org/d/000000458/tls-ciphersuite-explorer?orgId=1>
about
1.2% of our connections still use TLS 1.0, but this isn't broken down
between logged-in-user views and anon views.)
Open questions:
* Should we drop the anti-sniff checks on upload?
* If we do, should we forbid logins with IE 7, or something else to protect
the occasional IE 7 logged-in user from a hypothetical targeted drive-by
attack? (Is it actually worth doing work and testing it for this?)
* Should we add X-Content-Options: nosniff on files served from
upload.wikimedia.org too?
-- brion
Hi all,
as some of you might know, HHVM has decided some time ago to drop support
for PHP, choosing to only support Hack (Facebook's own PHP-derivative
language)[1].
This forced us to consider alternatives. In particular the last major
upgrade to PHP, PHP 7, was supposed to have greatly improved the
performance of the runtime, guaranteeing performance on par with HHVM.
Given that early tests[2] showed promising performance, we decided to work
on PHP7 support and on its rollout in production.
I'm happy to announce that PHP 7 is now available as a beta feature on all
wikis, and I encourage everyone to try it out and report bugs using the
#php7.2-support tag.
After this period of beta testing, we will proceed with a progressive
rollout to a growing percentage of users, and hopefully we'll complete the
transition in the next four months.
A huge thank you to all the people who worked hard to reach this goal!
Thanks,
Giuseppe
[1] https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
[2]
https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088854.html
--
Giuseppe Lavagetto
Principal Site Reliability Engineer, Wikimedia Foundation
Reminder: Technical Advice IRC meeting **today (Wednesday) 4-5 pm UTC** on
#wikimedia-tech.
Question can be asked in English, German & Persian.
The Technical Advice IRC Meeting is a weekly support event for volunteer
developers. Every Wednesday, two full-time developers are available to help
you with all your questions about Mediawiki, gadgets, tools and more! This
can be anything from "how to get started" over "who would be the best
contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
--
Michael F. Schönitzer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
For those who weren't aware, Jack Phoenix and I have drafted a Request
for Comment[1] and related initial patch[2] proposing to merge the logic
from the Theme extension[3] into MediaWiki core.
From the RfC: This will provide built-in functionality that skins can
implement in a simple and consistent manner, enabling user- or
site-selection of css variations of a given skin, such as a dark version
or a layout with more colours.
The RfC itself covers in detail the distinction between skins and themes
as well as several use cases and issues surrounding the current
situation, but the key point here is thus: with this functionality, we
will be able to not just more easily implement night[4], winter, and
accessibility[5] modes in skins such as Vector and Timeless, but also
much more consistently, and in a manner that can then be developed to
better and more consistently use the variables defined by the skins even
outside of the themes themselves.
Currently, the Theme functionality is limited to the extension itself
and a few skins that replicate key parts with varying amounts of
fidelity, which not only results in a bit of a mess in terms of code
fragmentation, but also limits what we can do with the skins themselves
due to the added dependency. We would like to fix this, and thus invite
everyone interested to review our proposal and please, comment if you
have concerns or see any issues.
-I
See:
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Themes_in_core
[2] https://gerrit.wikimedia.org/r/#/c/465451/
[3] https://www.mediawiki.org/wiki/Extension:Theme
[4]
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Nigh…
[5]
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Acce…
Hi developers,
This is Kaushik Reddy. I am currently working on few data science tools,
naming few pandas, seaborn, Matplotlib,NumPy etc with python.
Can I propose projects for wikimedia dealing with data science?
If you people agree to have projects in data science, I would like to
propose few within 3 days.
Will be waiting for your response.
Regards,
Kaushik.
Hi people,
This is Kaushik again. I have gone through the proposed GSoC'19 project
ideas, they are all good.
https://m.mediawiki.org/wiki/Google_Summer_of_Code/2019
But , I am looking for something which can be done with python. I also
think the above projects can be done with python befriended with java
script.( Just suggesting, no offense).
I am really optimistic that wikimedia would propose some projects dealing
with Data science or python for GSoC'19.
I actually have many ideas regarding the above mentioned topics.
I would bring them in a good form and would like to propose before you
people soon.
with regards,
Kaushik.
Hello,
Per CoC[1], the appealing processes follows like this:
"Only resolutions (such as bans) that last more than one week may be
appealed by people who were sanctioned. Reported victims can always appeal.
To appeal a decision of the Committee, the reported offender or reported
victim may contact the Technical Collaboration team's Community Health
group at techconductappeals(a)wikimedia.org and they will review the case.
Until an appeal is resolved, the prior resolution remains fully in effect. "
The problem is that "Community Health group" doesn't exist anymore[2] [3],
Technical collaboration team is also reorganized, leaving us in a situation
that we don't have an appeal body anymore. All people in the old group are
still active so if they receive an appeal, they can handle it but this is
not sustainable.
Hereby we need to determine an appealing body. Please comment on
https://www.mediawiki.org/wiki/Topic:Uay0vz6no8ayac3m about this matter.
[1] https://www.mediawiki.org/wiki/Code_of_Conduct/Cases
[2] https://meta.wikimedia.org/wiki/Community_Relations/Community_health
[3] https://phabricator.wikimedia.org/T199086
Best
--
Amir
Hi, i am pleased to say that gerrit.wikimedia.org PolyGerrit theme has been updated to match timeless (blue/red/green) instead of the plain grey.
this is what it looks like: https://phabricator.wikimedia.org/F28019595 in 2.15 and in 2.16: https://phabricator.wikimedia.org/F28019604
Thanks to thcipriani who played with my original change and made it look much much better (awesome), addressing feedback from Volker E.
Also thanks to Luca from upstream which came up with a original theme for GerritHub which my change is based on!