Hi all,
a minor security bug [1] has been fixed in the OAuth extension:
* a connected application could use the /identify endpoint to learn the
username of a user even if the application has been disabled.
* a connected application could use the /identify endpoint to learn the
username of a user even if the user was locked or blocked from login (this
could be problematic when OAuth is used for authentication, such as with
the OAuthAuthentication [2] extension).
The fix has been backported to all supported versions (those for MediaWiki
1.23, 1.26 and 1.27).
Gergő
https://www.mediawiki.org/wiki/User:Tgr_(WMF)
[1] https://phabricator.wikimedia.org/T148600
[2] https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Hey,
This is the 26th and 27th weekly update from revision scoring team that we
have sent to this mailing list. We forgot to send the update for last week!
Last week, we were featured in Research's quarterly review. In the last 3
months, we achieved our goals to expand the ORES extension to 6 wikis (we
made it to 8!) and to release datasets of article quality predictions. The
minutes from the quarterly review are not yet online, but once they are,
you'll be able to see them at [1].
Maintenance and robustness:
- We discussed and decided on a set of strategies for handling
goodfaith/naive DOS attacks on ORES[2]
- We fixed an i18n issue in Wiki Labels[3]
- We updated the article quality models (wikiclass/wp10) to use
revscoring 1.3.0[4]
- We investigated and solved a memory leak in our pre-caching utility[5]
- We configured celery to send its logs to a place where we can read
them for easier debugging[6]
- We deployed a set of schema changes to constrain the ORES Review Tools
database appropriately[7]
- Also worth noting is that the services cluster (SCB) has been
expanded[8]. ORES has now doubled in capacity
Datasets
- We discussed how to make the historical article quality dataset
available via quarry[8]. Regretfully, it seems that we'll not be able to do
that for at least a couple of months.
New development
- We've implemented embedding of machine-readable scores in a JS
variable on-wiki[9]. This will make it easier for tool developers to
experiment with new ways of displaying Special:RecentChanges more easily.
It's also a necessary precondition for adding color-based signaling of
ORES' confidence about an edit.
1.
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_metrics_and_activities…
2. https://phabricator.wikimedia.org/T148347 -- [Discuss] DOS attacks on
ORES. What to do?
3. https://phabricator.wikimedia.org/T139587 -- Revision not found error
unformatted and not localized
4. https://phabricator.wikimedia.org/T147201 -- Update wikiclass for
revscoring 1.3.0
5. https://phabricator.wikimedia.org/T146500 -- Investigate memory leak in
precached
6. https://phabricator.wikimedia.org/T147898 -- Send celery logs to
/srv/log/ores instead of /var/lib/daemon.log
7. https://phabricator.wikimedia.org/T147734 -- Review and deploy 309825
8. https://phabricator.wikimedia.org/T147903 -- Expand SCB cluster
9. https://phabricator.wikimedia.org/T146718 -- [Discuss] Hosting the
monthly article quality dataset on labsDB
10. https://phabricator.wikimedia.org/T143611 -- Embed machine readable
ores scores as data on pages where ORES scores things
Sincerely,
Aaron from the Revision Scoring team
Greetings,
Wikimedians, please review something we are working on for the Wikimedia
Foundation, the Technical Collaboration Guideline [0].
The Technical Collaboration Guideline (TCG) is a set of best practice
recommendations, for planning and communicating product and project
information to Wikimedia communities, in order to work better, together.
The TCG allows Wikimedia Foundation (WMF) Product teams and Wikimedia
communities to work together in a systematic way in the product development
and deployment cycle. It is hoped that the TCG is useful enough to be
utilized in planning and communications regarding any project, from anyone.
The TCG is intended to be flexible as plans and products change in
development; it is a guide whose contents will help build collaborative
relationships.
The initial draft of the TCG was written after discussions in small groups
with members of the Community Liaisons and Product Management teams, to
identify successes and failures in communication, and what we can do to
encourage collaboration with the communities. Over the next month, I am
seeking review and feedback from Wikimedia community members. All feedback
that is left will be read; if there is a case for immediate action, it will
be made. All feedback will be taken into consideration when editing the
next draft of the TCG. Please keep in mind that the TCG is intended to be
lightweight information and instruction and will not be completely
comprehensive. The TCG and the conversations about it are in English, but
comments from all languages are welcome.
Over the next few days, this invitation for review will be distributed
across the wikis.
Also, within the coming weeks, I'll be announcing a review on behalf of the
WMF's Design team. They have been working diligently over the past few
months to identify and define the purpose of design within the WMF, and
they are looking forward to sharing this statement of purpose with the
broader Wikimedia movement for comment. If you're interested, please be on
the lookout for this review announcement.
I look forward to reading your comments on the wiki [1].
0. https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline
1. https://www.mediawiki.org/wiki/Talk:Technical_Collaboration_Guideline
--
Keegan Peterzell
Technical Collaboration Specialist
Wikimedia Foundation
Hello,
We are proceeding with an unscheduled operation on servers that host
Gerrit and the continuous integration systems. Both are going to be
shortly unavailable over the course of next hour as we restart them.
Gerrit would be unavailable for a mew minutes. CI for an half an hour
or so. I will reenqueue changes in CI once the maintenance is completed.
Sorry for the short notice.
--
Antoine Musso
On Thu, Oct 20, 2016 at 10:20 AM, 魔法設計師 <shoichi.chou(a)gmail.com> wrote:
> 2016-10-19 0:45 GMT+08:00 Alexandros Kosiaris <akosiaris(a)wikimedia.org>:
>>
>> Hello,
>>
>> With the preamble of my opinion not being an authoritative point of
>> view at all, I should point out that Java/JVM based services are not
>> especially loved in WMF. Ops does not feel it has the capability of
>> supporting them. There are a few around like Gerrit, Cassandra,
>> ElasticSearch, Kafka but none of these is actually maintained by ops.
>> All of these have owners/maintainers outside of ops (entire teams in
>> some cases), with varying degrees of success. The question of whether
>> it should be Tomcat or Jetty, is a valid one, but serves to alleviate
>> only part of the problem (it's not like Ops hate tomcat but like
>> Jetty). So, there are probably a few social/administrative issues that
>> it might make sense to address first before handling the technical
>> part.
>
> I think what you means is : if the service is online,for administration ,
> a maintainer or a team is needed just like Gerrit,Cassandra, and
> ElasticSearch did. Not maintained by the OPs. The team need to be set
> first. Am I right?
Yes, that's the very least IMHO.
Hi,
In the RfC meeting for the Future of magic links RfC, it was agreed upon
to disable magic links for the MW 1.28 release by default and begin the
deprecation for Wikimedia sites. One of the subpoints was to provide
migration tools and similar functionality. For RFC and PMID links, they
were added to the default core interwiki map, and the Wikimedia one. But
for ISBN, it points to the local wiki, so an interwiki link doesn't make
sense.
The two main proposals are:
Virtual namespace ([[ISBN:0-7475-3269-9]]), which is similar to existing
link syntax (double brackets), but is also a bit magical since there
haven't been any new virtual namespaces since Special and Media in the
initial version of MW.
Parser function ({{#isbn:0-7475-3269-9}}), which is typically how new
syntax/functions are added, but is farther away from traditional link
syntax.
I would appreciate comments on
<https://phabricator.wikimedia.org/T148274> - I've written a patch for
the virtual namespace as a POC, but writing one for the parser function
if people prefer that, should be trivial.
-- Legoktm
Hi,
this is to let you know that kraz, the server that runs irc.wikimedia.org
had to be rebooted for a kernel upgrade.
If you have IRC clients on that server (i know some use it for
anti-vandal tools etc), and the clients don't auto-reconnect, please
make them connect again now. (And ideally fix them so they
automatically do it in the future).
Thank you
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer