Re: [Wikitech-l] Announcing a new security testing tool for MediaWiki extensions "phan-taint-check-plugin"

[zppix e]

Brian,
When you were talking about it in IRC it sounded cool, looking at the current 
project is even better! However can I suggest maybe making this into a wmflabs 
tool so we can choose to run certain repos without using our own personal 
ram/resources? Thank you for all you do.
Merry Christmas and Happy New Years (Happy Holidays)

--
Zppix
Volunteer Wikimedia Developer
Volunteer Wikimedia GCI2017 Mentor
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters.** 

> On Dec 11, 2017, at 7:40 PM, Greg Rundlett (freephile)  
> wrote:
> 
> Thanks Brian!
> 
> As an integrator, I'm often concerned about the quality of 3rd party
> extensions. This should be super useful. I hope to give feedback once I get
> this setup and run various checks with it.
> 
> Greg Rundlett
> https://qualitybox.us
> ___
> 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] Announcing a new security testing tool for MediaWiki extensions "phan-taint-check-plugin"

[Greg Rundlett (freephile)]

Thanks Brian!

As an integrator, I'm often concerned about the quality of 3rd party
extensions. This should be super useful. I hope to give feedback once I get
this setup and run various checks with it.

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

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.30 Available!

[Cindy Cicalese]

Hello everyone,

I am happy to announce the availability of the general release of MediaWiki 
1.30! 

MediaWiki 1.30 includes all changes released in the smaller 1.30.0-wmf.* 
software deployments to Wikimedia sites over six months, totaling almost 1500 
commits by around 116 unique authors. This is a large release that contains 
many new features and bug fixes. 

This is a summary of the major changes of interest to users and administrators:
* https://www.mediawiki.org/wiki/MediaWiki_1.30

You can always consult the RELEASE-NOTES-1.30 file for the full list of changes 
in this version. 

Full release notes:
* 
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_30/RELEASE-NOTES-1.30
* https://www.mediawiki.org/wiki/Release_notes/1.30

** 

Download: 
https://releases.wikimedia.org/mediawiki/1.30/mediawiki-1.30.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.30/mediawiki-core-1.30.0.tar.gz

GPG signatures: 
https://releases.wikimedia.org/mediawiki/1.30/mediawiki-1.30.0.tar.gz.sig  
(signed by Chad Horohoe)
https://releases.wikimedia.org/mediawiki/1.30/mediawiki-core-1.30.0.tar.gz.sig  
 (signed by Chad Horohoe)

Public keys: 
https://www.mediawiki.org/keys/keys.html

__
Cindy Cicalese
Product Manager, MediaWiki Platform
Wikimedia Foundation
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Announcing a new security testing tool for MediaWiki extensions "phan-taint-check-plugin"

[Brian Wolff]

Hello everyone,

For the last little while I have been working on a new tool
to automatically detect common security issues in MediaWiki
extensions.

The tool can detect a number of issues, including:
* XSS
** We include here using wfMessage( 'foo' )->text()
   when you should have used ->escaped() or ->parse().
* Sql injection
* Shell injection
* PHP deserialization vulnerabilities (A little buggy on this one)

In the future, it will likely also detect double escaping issues.

Of course, as with any static analysis tool, there will be instances
of false positives, as well as things it cannot detect.

I've now reached the stage where I feel the tool is useful,
and would really like people to test it out and give feedback.

Note: the tool has a requirement of php 7.0 (neither higher nor lower)
see https://www.mediawiki.org/wiki/Continuous_integration/Phan#Dependencies
for how to install php 7.0 if your system doesn't have it.

To test with your extension, simply do:

$ composer require --dev mediawiki/phan-taint-check-plugin

and then merge into the scripts directive of composer.json
  "scripts": {
 "seccheck": "seccheck-mwext",
 "seccheck-fast": "seccheck-fast-mwext"
  }
and simply run
composer seccheck

seccheck will take about 3 minutes and use lots of ram (~2 GB),
seccheck-fast won't test certain things involving hooks,
but will work in about 27 seconds and use much less ram.
This assumes that your extension is installed in the extensions/
subdirectory of MediaWiki.

In the future we may make this into a non-voting jenkins job.

If you are not making a MediaWiki extension, there is also
a "seccheck-generic" script you can use, which should work
with any PHP project. It is also possible to customize the script
for other projects that have custom escaping methods.
Generic mode is not well tested yet.

See the README for more information about the tool:
https://github.com/wikimedia/Phan-Taint-Check-Plugin/blob/master/README.md

Anyways, I hope this is useful, and am very eager to
hear feedback. I also hope that this will not only be useful
for Wikimedia, but also helpful to the third party extension
development community. Please test it and let me know what
you think.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FLIF for Wikimedia

[bawolff]

To be clear, there are generally no objections to "1) accept FLIF (and possibly
serve PNG thumbs for browsers without js" other than convince commons
it would be a good idea to accept the format. All the controversial
bit is converting files to FLIF. Accepting FLIF files for upload is
non-controversial if the communities want them.

--
Brian

On Mon, Dec 11, 2017 at 5:30 PM, Chico Venancio
 wrote:
> I concur with the extension idea.
> I'd add that have options for degrees of using FLIF would be a good idea as
> well. I.E. the decision could be to simply 1) accept FLIF (and possibly
> serve PNG thumbs for browsers without js), to 2) encourage FLIF use, or to
> 3)"force" FLIF by converting everything to FLIF and serving only FLIF
> versions to browsers.
>
> Even option 1 seems unlikely to gather support at this point, but it is a
> lot more likely than option 3.
>
> Chico Venancio
>
> 2017-12-11 14:22 GMT-03:00 Bartosz Dziewoński :
>
>> If you want to work on implementing support for FLIF, I would recommend
>> doing it as an extension (similar to e.g. https://www.mediawiki.org/wiki
>> /Extension:PdfHandler) rather than in MediaWiki core.
>>
>> --
>> Bartosz Dziewoński
>>
>>
>> ___
>> 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] Discovery Weekly Update for the week starting 2017-12-04

[Chris Koerner]

Hello,
This is the weekly update from the search team at the foundation for
the week starting 2017-12-04.

== Discussions==

=== Search ===
* Upgrading to ElasticSearch 5.5.x took a lot of smaller sections of
work to be completed [0]
** Complete a Kibana security release [1]
** Upgrading Logstash cluster to elastic 5.5.x [2]
** Upgrading all log producers to use the Logstash LVS endpoint [3]
* There was a HP RAID Battery issue on elastic2004 that has been resolved [4]
* There was an issue with forceSearchIndex.php hanging at the end of
the process when running on large wikis, so we disabled statsd
collection instead of replacing statsd [5]

=== Portal ===
* Fixed an issue where the logo on www.wikipedia.org is misaligned for
RTL languages on very small devices [6]
* Automation is nearly done for the Wikipedia.org portal site [7]

== FY 2017-18 Q2 (Oct-Dec) goals]==
This status was last updated 2017-12-08. [8]

[0] https://phabricator.wikimedia.org/T174662
[1] https://phabricator.wikimedia.org/T173685
[2] https://phabricator.wikimedia.org/T178412
[3] https://phabricator.wikimedia.org/T175242
[4] https://phabricator.wikimedia.org/T181412
[5] https://phabricator.wikimedia.org/T181716
[6] https://phabricator.wikimedia.org/T179273
[7] https://phabricator.wikimedia.org/T140159
[8] 
https://www.mediawiki.org/wiki/Discovery/Status_updates/2017-12-04#FY_2017-18_Q2_(Oct-Dec)_goals

---

Subscribe to receive on-wiki (or opt-in email) notifications of the
Discovery weekly update.

https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or
"Volunteer needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R

Yours,
Chris Koerner
Community Liaison
Wikimedia Foundation

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

Re: [Wikitech-l] FLIF for Wikimedia

[Chico Venancio]

I concur with the extension idea.
I'd add that have options for degrees of using FLIF would be a good idea as
well. I.E. the decision could be to simply 1) accept FLIF (and possibly
serve PNG thumbs for browsers without js), to 2) encourage FLIF use, or to
3)"force" FLIF by converting everything to FLIF and serving only FLIF
versions to browsers.

Even option 1 seems unlikely to gather support at this point, but it is a
lot more likely than option 3.

Chico Venancio

2017-12-11 14:22 GMT-03:00 Bartosz Dziewoński :

> If you want to work on implementing support for FLIF, I would recommend
> doing it as an extension (similar to e.g. https://www.mediawiki.org/wiki
> /Extension:PdfHandler) rather than in MediaWiki core.
>
> --
> Bartosz Dziewoński
>
>
> ___
> 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] FLIF for Wikimedia

[Bartosz Dziewoński]

If you want to work on implementing support for FLIF, I would recommend 
doing it as an extension (similar to e.g. 
https://www.mediawiki.org/wiki/Extension:PdfHandler) rather than in 
MediaWiki core.


--
Bartosz Dziewoński

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

Re: [Wikitech-l] FLIF for Wikimedia

[Max Semenik]

10 дек. 2017 г. 23:42 пользователь "Ruben Kelevra" 
написал:

So... to break the current discussion down, there is no hard "we
don't want this format" yet shown up.


Nope, you've been provided ample reasons why a phab ticket requesting this
will probably be declined on the spot.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FLIF for Wikimedia

[Ruben Kelevra]

Hey Brian,

On 11.12.2017 00:10, Brian Wolff wrote:
> Maybe not a hard no, but I would rate the probability as somewhere around
> 1%.
> 
> If you really wanted to push this (with the understanding that its probably
> not going anywhere) I would say make a report, comingup with a solid case
> with a solid implementation plan, including:
> * what is the fallback plan for non js users and users with old browsers
> * what would the bandwidth saving be in typical usage on typical wikipedia
> pages
> * what is the server side latency on an uncached hit where we have to
> generate a thumbnail for the request, compared to existing formats
> *what is the client side latency to render with the polyfill compared to
> native format. What happens during rendering? What about people using
> old-generation cell phones with lackluster cpus? Is it in a separate worker
> thread or does it stop the main js thread? What is the general affect to
> the user during polyfil loading.
> *combining server side latency, client side latency bandwidth difference,
> etc what is the overall difference in loading time for the user on a
> typical wikipedia page- and what is it for a (client side) cached hit vs
> (server side i.e. thumb is already rendered) vs totally uncached where
> thumbnail has to be converted on the fly.
> 
> I think that would be the minimum information required to convince people
> to do this, and i doubt that that would be enough unless the numbers are
> super good.
Thanks alot for this open feedback, Brian. I think about that. :)


Best regards

Ruben

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