Re: [Wikitech-l] Reducing the environmental impact of the Wikimedia movement

[Ricordisamoa]

Server consumption of course but what about the impact of email, food, 
transport etc?

Earth Hour: switch the wikis to a dark skin

Il 30/03/2016 09:27, Lukas Mezger ha scritto:

Dear readers of the Wikitech mailing list,

I am a member of the Wikipedia community and I have started a project to
reduce the environmental impact of the Wikimedia movement
. The main idea is to
use renewable energy for running the Wikimedia servers and the main reason
for this is that by doing so, Wikipedia can set a great example for
environmental responsibility in the entire internet sector.

My project was started after Greenpeace USA published a report
 about the
energy consumption of the biggest sites on the Internet in 2015 and in
which Wikipedia, to my astonishment, performed poorly, receiving a "D"
score and only passing because of the Wikimedia Foundation's openness about
its energy consumption.

I would very much like to change that and set up a page called "Environmental
impact " on Meta. I
have already discussed the issue with a few people both from the Wikimedia
Foundation's management and from the Wikimedia community and have received
positive responses.

In order to further advance the project, I would like to learn more about
how much energy Wikipedia's servers use. As far as I can tell, these
figures are not public, but I believe they could very well be.

Also, I am interested to learn how changing a server site's energy sources
can be carried out on the operations side since the United States energy
sector hasn't been completely deregulated yet.

So, thank you very much for any comments! Maybe there also is an even
better forum to discuss these questions?

Finally, if you would like to support my project, please consider adding
your name to this list
.
Thank you.
Kind regards,

Lukas Mezger / User:Gnom 
___
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] The Revision scoring weekly update

[Amir Ladsgroup]

Hey,
This is the fifth weekly update for revision scoring team that we sent to
this mailing list.

*New developments:*

   - We got Swedish basic model ready to deloy, likely to happen in the
   next week [1] [2]


   - We generated list of bad words for every Wikipedia with more than 100K
   articles (with a few exceptions) [3]


*Maintenance and robustness:*

   - We enabled CORS for Wikimedia wikis in wikilabels and now we won't let
   you do write actions via GET [4]


   - We are using systemd watchdogs in precaching to be sure it stays
   alive. [5]


   - We are changing some settings in nginx and uwsgi in order to finalize
   moving to prod [6]


1. https://phabricator.wikimedia.org/T131450
2. https://phabricator.wikimedia.org/T135604
3. https://phabricator.wikimedia.org/T134629
4. https://phabricator.wikimedia.org/T135377
5. https://phabricator.wikimedia.org/T135941
6. https://phabricator.wikimedia.org/T135655


Sincerely,
The Revision scoring team
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] AuthManager is now in core and 1.27

[Brad Jorsch (Anomie)]

TL;DR: AuthManager is now in core, although it's currently behind a feature
flag that is disabled on Wikimedia wikis. We're hoping that feature flag
can be removed from 1.27 before release. Help fix extensions!


AuthManager is a new authentication system for MediaWiki that allows for
easily plugging in multiple authentication methods, non-password-based
authentication methods (such as authentication by redirecting to a
third-party service), secondary authentication methods like two-factor
auth, and so on. We've[1] been working on it for over a year now, and it's
getting close to being done. Last week, we merged the core patches[2] and
fixes for extensions bundled in the tarball. These were also backported to
the REL1_27 branch. Documentation is now at
https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager,
please feel free to ask questions or to improve it.

AuthManager is currently behind a feature flag, $wgDisableAuthManager,
which can be set to use the old authentication system rather than
AuthManager. For Wikimedia wikis, our next step is to fix the rest of the
extensions we use,[3] then (gradually) enable AuthManager while making sure
things don't break.[4] We plan to default the flag to enabling AuthManager
in master soon,[5] and we hope to be able to remove it entirely from 1.27
before release.[6]

If you maintain an extension in Gerrit and it needs updating for
AuthManager, we've probably already filed a task in Phabricator for you!
Look at the subtasks of T110282 for extensions deployed on Wikimedia wikis,
or of T110291 for other extensions. Besides the information in the tasks,
we've also compiled a list of common things needing updating and some
solutions.[6]

If you run a wiki, you might need to set $wgDisableAuthManager = true if
you have extensions that break. Remember, though, this isn’t a permanent
solution, and you’ll need to update your extensions reasonably soon.

If you run a bot that still uses API action=login (and isn't using it for
BotPasswords), it's time to update! If you have an interactive application
that logs in with API action=login, you'll want to prepare to start using
action=clientlogin. If you want some visibility, the tracking task for
clients is T134945.

If you find bugs in AuthManager, please report them in Phabricator and
include the #Reading-Infrastructure-Team tag.

See also previous AuthManager announcements:
* https://lists.wikimedia.org/pipermail/wikitech-l/2016-January/084501.html
*
https://lists.wikimedia.org/pipermail/mediawiki-api/2016-January/003686.html
*
https://lists.wikimedia.org/pipermail/mediawiki-api/2016-January/003688.html


[1]: Mainly Gergő Tisza and I, with help from Bryan Davis and Chris Steipp.
[2]: https://gerrit.wikimedia.org/r/#/c/195297/,
https://gerrit.wikimedia.org/r/#/c/240052/,
https://gerrit.wikimedia.org/r/#/c/265201/, and
https://gerrit.wikimedia.org/r/#/c/282202/
[3]: https://phabricator.wikimedia.org/T110282
[4]: https://phabricator.wikimedia.org/T135504
[5]: We tried to do it already, but it broke all the selenium tests due to
changes to account creation. See https://phabricator.wikimedia.org/T135884
for progress on that.
[6]: https://phabricator.wikimedia.org/T135498
[7]:
https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/Updating_tips

--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Git/Gerrit/Code Review technical documentation updates

[Chad]

On Mon, May 23, 2016 at 9:42 AM Bernd Sitzmann  wrote:

> I think it would be great to favor git fetch and git rebase over git pull
> and merge[1] in the beginners documentation so people don't start out with
> bad habits.
>
> [1] https://wikitech.wikimedia.org/wiki/Help:Git_rebase
>
> Bernd
>
>
`git pull -r` for life :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Git/Gerrit/Code Review technical documentation updates

[Bernd Sitzmann]

I think it would be great to favor git fetch and git rebase over git pull
and merge[1] in the beginners documentation so people don't start out with
bad habits.

[1] https://wikitech.wikimedia.org/wiki/Help:Git_rebase

Bernd

On Mon, May 23, 2016 at 5:37 AM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:

> 2016-05-23 14:22 GMT+03:00 Andre Klapper :
>
> > Some stuff I did not touch (as perfect is the enemy of good).
> > For example, I'm still wondering about the role of
> > https://www.mediawiki.org/wiki/Git_for_dummies compared to
> > https://www.mediawiki.org/wiki/Gerrit/Getting_started and
> > https://www.mediawiki.org/wiki/Gerrit/Tutorial .
> >
>
> The original title of "Gerrit/Getting started" when I created it was
> "Git/TLDR". I explained the reason for this in a  comment on top of
> it. It is still relevant today:
> * "Gerrit/Tutorial" is 16 pages when printed.
> * "Git for dummies" is 9 pages when printed.
> * "Gerrit/Getting started" is 1 page when printed.
>
> I don't know about the other pages, but the number of pages in
> "Gerrit/Getting started" is very much by design, and I regularly check that
> it still conforms to that design.
>
> "Gerit/Tutorial" is evidently[1] more popular despite being the longest,
> which I find surprising, but of course I'm biased. (It may or may not have
> something to do with search terms.)
>
> [1]
>
> https://tools.wmflabs.org/pageviews/?project=mediawiki.org=all-access=user=2016-03-01=2016-05-20=Git_for_dummies|Gerrit/Getting_started|Gerrit/Tutorial
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> 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] Wired article about machine learning

[Aaron Halfaker]

Just a quick thought that I shared in IRC earlier.

 AI isn't magical.  It's pretty cool, but you're not going to have a
> conversation with ORES
> .
>

It's not false that we are closer to strong "conversational" AI than ever
before.  Still, in practical terms, we're pretty far away from not needing
to program anymore.  I find that articles like this are more fantastical
than informative.  I guess it is interesting to think about where we'll be
when we can have an abstract conversation with a computer system rather
than the rigid specifics of programming, but I'm with Brian -- this seems
to be a cycle.  Though, I'd say the media does boom and bust, but the
research carries on relatively consistently since AI researchers are
usually less interested in the hype.

In the ORES project, we're using the most simplistic "AIs" available --
classifiers.  Still these dumb AIs can still help us to do amazing things
(e.g. review all of RecentChanges in 50x faster or augment article
histories with information about the *type of change* made).  IMO, it's
these amazing and powerful things that dumb, non-conversational AIs can do
that is very powerful and a little scary
.
We're hardly taking advantage of that at all.  I think that's where the
next big revolution with AI is taking place right now.  It's going to
change a lot of things and infect many aspects of our life (and in many
ways it already has).

-Aaron

On Fri, May 20, 2016 at 2:43 PM, Purodha Blissenbach <
puro...@blissenbach.org> wrote:

> I see only an ad to support Wired.
> Purodha
>
>
> On 20.05.2016 20:11, Pine W wrote:
>
>> Seems like a good summary: http://www.wired.com/2016/05/the-end-of-code/
>>
>> Comments welcome, especially from Wikimedia AI experts who are working on
>> ORES.
>>
>> Pine
>> ___
>> 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] RFC: Add Content-Security-Policy header to MediaWiki

[Brian Wolff]

On Monday, May 23, 2016, Pine W  wrote:
> With the disclaimer that I'm not a security engineer and that I understand
> only parts of this proposal, in general this strikes me as a good idea. It
> seems to me that trying to develop a comprehensive list of what tools /
> scripts this proposal would likely break, how important those breaks are,
> and who could fix them and when, would help with developing a roadmap
> toward implementing this proposal with appropriate mitigation and
> communication.

At this stage, im just not sure. Its certainly going to be a lot and its
going to especially hit the older scripts hard. (As far as tools - if you
mean tool labs, i dont expect that to be affected). We would have a better
handle of what will be affected once the report-only mode is implemented,
which would allow us to get a list of everything that will break.

That said, should the rfc get approved, i would definitely put together a
list of common examples/patterns that would break.

Keep in mind also, we dont have to do this all at once - if there is some
wiki which seems like it is going to be less affected then others, we can
do them first.

> It seems to me that this is the kind of project for which product
community
> liasons are well suited to help with developing and implementing a rollout
> plan. Is there any chance of getting a CL to help with this project?

Hmm. I have no idea. That's something I will have to discuss with them.


--
Bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Brian Wolff]

On Monday, May 23, 2016, Tyler Romeo  wrote:
> First, as I expected, this proposal is to use CSP wit the "unsafe-eval"
> option enabled for both style-src and script-src. This means the
JavaScript
> eval() function can be used freely, and inline CSS via the style attribute
> can still be used. Combined with the "default-src *" policy, which I
> mention later in this email, this means an attacker can just use XHR to
> download an external script and eval() it, thus defeating the entire point
> of CSP: to prevent XSS attacks.
>
> I understand the reason behind this is because we store scripts in
> localStorage as cache and eval() them upon page load (which is perhaps the
> worst abuse of browser technology I have ever seen). Not allowing both
> inline scripts and styles and eval()ed code is one half of the two-sided
> CSP coin, and eliminating it keeps open a pretty large attack vector. I
> don't believe it's appropriate to sacrifice security for a quick kludge
> that is used to improve the performance hole opened by the large
> fragmentation of our JavaScript codebase.
>

Yes, unsafe-eval in scripts is for the localStorage hack. Unsafe-eval in
styles is because there is a limit to how much of the world i can
reasonably expect to break (I suppose for style we could in theory
dynamically gather all the inline styles up, put them in a rl module and
make them non-inline. Sounds kind of complex though. Maybe something to
think about later down the line).

In regards to the XHR attack - my understanding is, if the user already has
the ability to execute javascript, all is pretty much lost. Even if
script-src is super restricted, (which is pretty unfeasible if we still
want  to allow user scripts) provided the script can load user controlled
data, presumably the attacker could just reimplement a js interpreter in
js. The only situation i see it helping is if the attack vector is length
limitted.

The way I see it - the main benefit of not allowing eval would be to
prevent users doing silly things with it (or for that matter prevent
libraries like jquery.ui.datepicker from doing silly things)

For unsafe-inline in style - i was under the impression (which may be
wrong) that the main benefits for banning were to:
* prevent data exfiltration (via background-image: etc, unclosed stuff in

Re: [Wikitech-l] Wikimedia Git/Gerrit/Code Review technical documentation updates

[Amir E. Aharoni]

2016-05-23 14:22 GMT+03:00 Andre Klapper :

> Some stuff I did not touch (as perfect is the enemy of good).
> For example, I'm still wondering about the role of
> https://www.mediawiki.org/wiki/Git_for_dummies compared to
> https://www.mediawiki.org/wiki/Gerrit/Getting_started and
> https://www.mediawiki.org/wiki/Gerrit/Tutorial .
>

The original title of "Gerrit/Getting started" when I created it was
"Git/TLDR". I explained the reason for this in a  comment on top of
it. It is still relevant today:
* "Gerrit/Tutorial" is 16 pages when printed.
* "Git for dummies" is 9 pages when printed.
* "Gerrit/Getting started" is 1 page when printed.

I don't know about the other pages, but the number of pages in
"Gerrit/Getting started" is very much by design, and I regularly check that
it still conforms to that design.

"Gerit/Tutorial" is evidently[1] more popular despite being the longest,
which I find surprising, but of course I'm biased. (It may or may not have
something to do with search terms.)

[1]
https://tools.wmflabs.org/pageviews/?project=mediawiki.org=all-access=user=2016-03-01=2016-05-20=Git_for_dummies|Gerrit/Getting_started|Gerrit/Tutorial

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikimedia Git/Gerrit/Code Review technical documentation updates

[Andre Klapper]

[For your info]

I've spend some time in the last weeks rewriting and cleaning up our
technical Git / Gerrit / Code Review documentation on mediawiki.org.

135 edits later, things feel a bit cleaner. :)

=== Changes ===

There is a central Git/Gerrit "Troubleshooting" page linked from the
most relevant pages, instead of separate sections on three or four
different pages which partially duplicated content (setting up Git and
Gerrit on different operating systems had similar problems and missing
central information). 
Some rather specific subpages were merged into existing pages (e.g.
into "Gerrit/Advanced usage").
The entrance page https://www.mediawiki.org/wiki/Gerrit has a
"Prerequisites" section and the sections are now structured by usecase
/ type of user. 
Some "too much detail" content was also removed (like the history of
the Git and Gerrit software; you can check Wikipedia as it's irrelevant
if you want just to get your patch done).

Full list of changes: https://phabricator.wikimedia.org/T134256#2317711

=== No changes ===

Some stuff I did not touch (as perfect is the enemy of good). 
For example, I'm still wondering about the role of 
https://www.mediawiki.org/wiki/Git_for_dummies compared to 
https://www.mediawiki.org/wiki/Gerrit/Getting_started and 
https://www.mediawiki.org/wiki/Gerrit/Tutorial .
Plus I still consider the screenshots of command line text output
distractive on https://www.mediawiki.org/wiki/Gerrit/Tutorial .

=== Thank you ===

Thank you a lot to everybody who provided feedback, answers to my
Gerrit questions, and helped editing those pages!

=== Next steps ===

After this technical documentation exercise, the next steps will focus
on soft / social+organizational aspects of code review:
* https://phabricator.wikimedia.org/T129068
  Improve code contribution guidelines for patch authors by fixing
  https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews etc
* https://phabricator.wikimedia.org/T129067
  Agree on + document a structured, standardized approach for 
  reviewing code contributions by fixing
  https://www.mediawiki.org/wiki/Gerrit/Code_review etc.

Needless to say, your help is very welcome. 
More information to come soon.

Cheers,
andre

-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Tyler Romeo]

First, as I expected, this proposal is to use CSP with the "unsafe-eval"
option enabled for both style-src and script-src. This means the JavaScript
eval() function can be used freely, and inline CSS via the style attribute
can still be used. Combined with the "default-src *" policy, which I
mention later in this email, this means an attacker can just use XHR to
download an external script and eval() it, thus defeating the entire point
of CSP: to prevent XSS attacks.

I understand the reason behind this is because we store scripts in
localStorage as cache and eval() them upon page load (which is perhaps the
worst abuse of browser technology I have ever seen). Not allowing both
inline scripts and styles and eval()ed code is one half of the two-sided
CSP coin, and eliminating it keeps open a pretty large attack vector. I
don't believe it's appropriate to sacrifice security for a quick kludge
that is used to improve the performance hole opened by the large
fragmentation of our JavaScript codebase.

Second, the proposal is to use the nonce-$RANDOM attribute for inline
scripts, but to cache the nonce for non-logged-in users. Does this mean
that the same nonce will be delivered to multiple pages and/or users?
Because that is a violation of the CSP spec, which says "If a server
delivers a nonce-source expression as part of a police, the server MUST
generate a unique value each time it transmits a policy." [0] Thus we
cannot use nonces in this way. Are these scripts whose contents we know
beforehand? Because then we can just use the hash-source policy.

(Not to mention that nonce-source and hash-source policies are part of CSP
2, which is not supported in the latest IE, Safari, or Opera Mini. What is
the plan to support these browsers? Fall back to unsafe-inline? Possibly
use a solution similar to what Dropbox used for their CSP deployment [1].)

Finally, as stage 1 hints at and as I mentioned above, there are a lot more
than just style-src and script-src, such as font-src, media-src, frame-src,
manifest-src, etc. Why are these not addressed, and instead just left to
the default policy of "default-src *"? Do we allow iframes on Wikipedia
pointing at arbitrary domains? At the very least, a scheme-source policy
can be used to enforce HTTPS.

[0] https://w3c.github.io/webappsec-csp/
[1]
https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Mon, May 23, 2016 at 1:18 AM, Pine W  wrote:

> With the disclaimer that I'm not a security engineer and that I understand
> only parts of this proposal, in general this strikes me as a good idea. It
> seems to me that trying to develop a comprehensive list of what tools /
> scripts this proposal would likely break, how important those breaks are,
> and who could fix them and when, would help with developing a roadmap
> toward implementing this proposal with appropriate mitigation and
> communication.
>
> It seems to me that this is the kind of project for which product community
> liasons are well suited to help with developing and implementing a rollout
> plan. Is there any chance of getting a CL to help with this project?
>
> Thanks for the initiative,
>
> Pine
>
> Pine
> On May 22, 2016 18:18, "Brian Wolff"  wrote:
>
> > So the RFC process page says I should email wikitech-l to propose an RFC,
> > thus:
> >
> > Content-Security-Policy (CSP) header is a header that disables certain
> > javascript features that are commonly used to exploit XSS attacks, in
> > order to mitigate the risks of XSS. I think we could massively benefit
> > from using this technology - XSS attacks probably being the most
> > common security issue in MediaWiki. The downside is that it would
> > break compatibility with older user scripts.
> >
> > Please see the full text of my proposal at
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
> >
> > The associated phabricator ticket is:
> > https://phabricator.wikimedia.org/T135963
> >
> > I'd appreciate any comments anyone might have.
> >
> > Thanks,
> > Brian
> >
> > ___
> > 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