Re: [Wikitech-l] Announcing a new security testing tool for MediaWiki extensions "phan-taint-check-plugin"
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"
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!
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"
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
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
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
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
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
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
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