Re: [Wikitech-l] GSOC-2014: Project Proposal for A system for reviewing funding request
@Gryllida, I really appreciate your feedback. They really helped me a lot. And thanks again for your time. Currently I'm modifying my proposal according to your feedback (Have done some modifications and need to do some more). As this is research oriented project, some details provided in the proposal may change according to the requirements identified in the 1st phase of the project. So I think feedback from all of you will help me to refine the requirements of the project. As the requirements are not fully refined yet, I have included only a rough time line that is also need to be refined at the end of each phase for the next phase. And certainly I am looking forward for feedback and be flexible to take them into account as it is a basic way of learning. I am a quick learner and interested in challenging work. So I am looking forward to contribute to this project. On Sun, Mar 30, 2014 at 6:01 AM, Gryllida gryll...@fastmail.fm wrote: Hi Maduranga, I had shown you that your first mock picture may be changed a bit, and linked you to a couple relevant pages which describe the system you'd be developing in more detail. Now I also noticed that in the past experience section, I would suggest that you provide links to your code contributions. The reviewers will want to see what you coded without manually looking you up on the web. As a part of what you'd expect, if approved, would be thorough feedback from your mentors and Grant Review Committees multiple times throughout your work. I hope you are sufficiently flexible to take the feedback into account. It's a challenging task there. The mentors would also provide you with code-base from a previous project which did similar tasks. Gryllida. On Sun, 30 Mar 2014, at 4:35, Maduranga Siriwardena wrote: @Gryllida, Again thank you for the reply and sorry for being late to reply back (last few days I was busy with a conference in my internship place). I have one more question. What is meant by https://meta.wikimedia.org/wiki/Grants:IdeaLab/Application_scoring_system- roles and expectations @ IdeaLab (this is for any ideas, not just grants, ie GSoC things can also go there) In your first reply(specially this is for any ideas, not just grants). And please inform if there is any improvement needed to the proposal. Regards, Maduranga On Tue, Mar 25, 2014 at 4:04 PM, Gryllida gryll...@fastmail.fm wrote: Great! On Thu, 20 Mar 2014, at 3:02, Maduranga Siriwardena wrote: @Gryllida Thank you for the reply. Sorry for misunderstanding. As it is mentioned that the Admin person who is creating the new grant campaign can create the review criteria, the area shown as a text box can be of different sorts. It is just a representation of the scoring criteria. Actually I did not have much understanding about what would be the scoring criteria. Your explanation really helped me to understand the use case. Regards, Maduranga On Wed, Mar 19, 2014 at 5:10 PM, Gryllida gryll...@fastmail.fm wrote: It is a few questions with a score (an integer) on each. Possibly also one textbox. I.e. budget ok? 1 2 3 4 5 6 X scope / multi project impact? 1 2 3 4 5 6 X impact substantial? 1 2 3 4 5 6 X impact to continue after grant ends? 1 2 3 4 5 6 X ok to fund? 0 1 X comments (posted to grant applications talk pages after reviewing ends, but anonymous) | | (a text box) | I have forwarded your initial message to one of the mentors, so I think they'd hand you some small test tasks to check your skills and add you in to the GSOC project. (I have found 3-4 students interested and forwarded them all so I hope you'll all make it to completion!) Gryllida. On Wed, 19 Mar 2014, at 22:35, Maduranga Siriwardena wrote: @Gryllida, Previously I checked the page [1]. But I couldn't find much details about how the scoring is done. So can you please elaborate how the scoring is done so that I can design how the scoring form should look like? [1] https://meta.wikimedia.org/wiki/User:Gryllida/sandbox Regards, Maduranga. On Wed, Mar 19, 2014 at 4:51 PM, Gryllida gryll...@fastmail.fm wrote: The score really should be something different from a textbox imo. See more detail I could locate about this idea: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Application_scoring_system-rolesandexpectations @ IdeaLab (this is for any ideas, not just grants, ie GSoC things can also go there)
Re: [Wikitech-l] HTML templating systems MediaWiki - is this summary right?
div class={{something}}/div is
vulnerable, if something is set to 1234 onClick=doSomething()
$html = Html::element( 'div', array( 'class' = $anything ),
$anythingElse
I see. Sorry but where I disagree is that the quote me this replacement
is a lawful case for the template engine.
I'm not sure I understand what you're saying here. Do you mean
makesafeString in your example shouldn't quote the text, but should instead
remove space characters?=
What I am saying is that the parsing and escaping scheme we need is much
simpler if you disallow the use case of passing the template engine
something that is not data.
Let me explain as this as it has to do more with correctness that with
security per se:
A template engine objective is to separate data from markup. In your
example you are passing the template 'class=anything' or
'onclick=something' neither class nor onclick are data. Thus what I
am arguing is that the template engine should not support the use case of
add any random attribute or javascript to my html element with the right
set of quotes as a lawful use case. The template engine should not be
expected to parse and insert code and onclick is code.
With a new template engine our main objective should be to separate data
from markup, not supporting an style of coding that includes onClick
attributes mixed with HTML which was prevalent years ago or css classes
mixed with controller code.
On my experience reducing use cases for template engine to just data
handling while having specific functions that deal with links and
translations simplifies the escaping problem greatly as you do not need
context aware escaping. You can js-escape any piece of data sent to the
engine cause you know you do not support the use case of sending javascript
to be inserted.
On Wed, Mar 26, 2014 at 6:41 PM, Chris Steipp cste...@wikimedia.org wrote:
On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz nu...@wikimedia.org wrote:
Additionally, how you escape a plain parameter like class vs. an
href vs. a parameter that is inserted into a url vs. an id attribute are
all different escaping strategies.
Urls in the template engine need to be handled on their own, sure. But
what
template engine does not work in this fashion? There are three separate
entities you normally deal with when doing replacement: translations,
urls and plain attributes.
$html = Html::element( 'div', array( 'class' = $anything ),
$anythingElse
I see. Sorry but where I disagree is that the quote me this replacement
is a lawful case for the template engine.
I'm not sure I understand what you're saying here. Do you mean
makesafeString in your example shouldn't quote the text, but should instead
remove space characters?
The line above is doing a lot
more than purely templating and on my opinion it does little to separate
data and markup. Which is the very point of having a template engine.
But if you consider that one a lawful use case, you are right. The
example
I provided does not help you.
On Wed, Mar 26, 2014 at 6:15 PM, Chris Steipp cste...@wikimedia.org
wrote:
On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
On 2014-03-26, 9:32 AM, Nuria Ruiz wrote:
The issue is that they apply the same escaping, regardless of the
html context. So, in Twig and mustache, div
class={{something}}/div
is
vulnerable, if something is set to 1234 onClick=doSomething().
Right, the engine would render:
div class=1234 onClick=doSomething() /div
because it only escapes HTML by default.
Now, note that the problem can be fixed with div
class={{makeStringSafe
something}}
Where makestringSafe is a function defined by us and executed
there
that
escapes to our liking.
How does a custom function jammed into the middle of a Mustache
template
fix the issue when the issue is not that foo={{something}} doesn't
escape, but is that quoting is needed instead of escaping, and
Mustache
isn't context sensitive so neither Mustache or a custom function know
that foo={{something}} is an attribute value in need of quoting?
Exactly. Additionally, how you escape a plain parameter like class vs.
an
href vs. a parameter that is inserted into a url vs. an id attribute
are
all different escaping strategies. So there would be many different
makeStringSafe and probably quoteAndMakeStringSafe
functions,
and code review would have to make sure the right one was being used in
the
right place. Which means someone who is familiar with all of the xss
techniques would need to code review almost all the templates.
For comparison, using our current html templating (as much as it
sucks):
$html = Html::element( 'div', array( 'class' = $anything ),
$anythingElse
);
The developer doesn't need to have any knowledge of what escaping needs
to
apply to the
Re: [Wikitech-l] HTML templating systems MediaWiki - is this summary right?
Allow me to just put this out there: using handlerbars or mustache or
anything similar to it is a *terrible* idea for MediaWiki. {{this is
escaped}} and {{{this is not escaped}}}. The only difference is an extra
brace on each side, and considering how many developers here are also
familiar with writing wikitext, the probability of an accidental security
vulnerability would increase significantly.
If we were to use a string-based templating engine (and looking at the
progress of gwicke's work, it's more likely we'll go DOM-based), we'd want
something that, at the very least, does not give the opportunity for a
screwup like this.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
On Sun, Mar 30, 2014 at 5:23 AM, Nuria Ruiz nu...@wikimedia.org wrote:
div class={{something}}/div is
vulnerable, if something is set to 1234 onClick=doSomething()
$html = Html::element( 'div', array( 'class' = $anything ),
$anythingElse
I see. Sorry but where I disagree is that the quote me this
replacement
is a lawful case for the template engine.
I'm not sure I understand what you're saying here. Do you mean
makesafeString in your example shouldn't quote the text, but should
instead
remove space characters?=
What I am saying is that the parsing and escaping scheme we need is much
simpler if you disallow the use case of passing the template engine
something that is not data.
Let me explain as this as it has to do more with correctness that with
security per se:
A template engine objective is to separate data from markup. In your
example you are passing the template 'class=anything' or
'onclick=something' neither class nor onclick are data. Thus what I
am arguing is that the template engine should not support the use case of
add any random attribute or javascript to my html element with the right
set of quotes as a lawful use case. The template engine should not be
expected to parse and insert code and onclick is code.
With a new template engine our main objective should be to separate data
from markup, not supporting an style of coding that includes onClick
attributes mixed with HTML which was prevalent years ago or css classes
mixed with controller code.
On my experience reducing use cases for template engine to just data
handling while having specific functions that deal with links and
translations simplifies the escaping problem greatly as you do not need
context aware escaping. You can js-escape any piece of data sent to the
engine cause you know you do not support the use case of sending javascript
to be inserted.
On Wed, Mar 26, 2014 at 6:41 PM, Chris Steipp cste...@wikimedia.org
wrote:
On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz nu...@wikimedia.org
wrote:
Additionally, how you escape a plain parameter like class vs. an
href vs. a parameter that is inserted into a url vs. an id attribute
are
all different escaping strategies.
Urls in the template engine need to be handled on their own, sure. But
what
template engine does not work in this fashion? There are three separate
entities you normally deal with when doing replacement: translations,
urls and plain attributes.
$html = Html::element( 'div', array( 'class' = $anything ),
$anythingElse
I see. Sorry but where I disagree is that the quote me this
replacement
is a lawful case for the template engine.
I'm not sure I understand what you're saying here. Do you mean
makesafeString in your example shouldn't quote the text, but should
instead
remove space characters?
The line above is doing a lot
more than purely templating and on my opinion it does little to
separate
data and markup. Which is the very point of having a template engine.
But if you consider that one a lawful use case, you are right. The
example
I provided does not help you.
On Wed, Mar 26, 2014 at 6:15 PM, Chris Steipp cste...@wikimedia.org
wrote:
On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
On 2014-03-26, 9:32 AM, Nuria Ruiz wrote:
The issue is that they apply the same escaping, regardless of
the
html context. So, in Twig and mustache, div
class={{something}}/div
is
vulnerable, if something is set to 1234 onClick=doSomething().
Right, the engine would render:
div class=1234 onClick=doSomething() /div
because it only escapes HTML by default.
Now, note that the problem can be fixed with div
class={{makeStringSafe
something}}
Where makestringSafe is a function defined by us and executed
there
that
escapes to our liking.
How does a custom function jammed into the middle of a Mustache
template
fix the issue when the issue is not that foo={{something}} doesn't
escape, but is that quoting is needed instead of escaping, and
Mustache
isn't context sensitive
[Wikitech-l] ogv.js media player update: Flash and GPU acceleration
I spent a little more time the last few weekends on ogv.js (JavaScript-based player for Ogg Theora and Vorbis media in IE and Safari) and have gotten two major things working: * an all-Flash version -- should work in older IE and Safari versions that can't run the JS code * optional GPU acceleration with WebGL or Flash Stage3D where available More details on my blog: https://brionv.com/log/2014/03/29/ogv-js-now-in-webgl-and-flash-flavors/ The Flash version generally runs a bit faster than the JS version on IE 10/11, about the same as JS on Safari 6.1/7, and slower than JS on current Chrome and Firefox. Note that the player demo page currently requires IE 9 or later although the player itself should work on IE 6/7/8. I've also compared performance to the Cortado Java applet we currently use -- Cortado is still a little faster in terms of CPU usage, but getting the applet to actually *run* with the current version of Java is a nightmare -- even the signed version of the applet from theora.org requires adding a security exception -- whereas JS or Flash just works. GPU acceleration in both JS and Flash combines YCbCr-RGB colorspace conversion into the drawing step and can be a *huge* speed boost at higher resolutions. At 360p or 160p it's a modest improvement of a couple milliseconds per frame on my test machines. Note that WebGL is available in IE 11, but is disabled by default in current versions of Safari (and cannot be enabled on iOS without a jailbreak). The main missing feature left is seeking, which I think can be left for later. I expect to do a bit more performance tuning and code cleanup, but I think it's time to devise some integration into TimedMediaHandler so people can try it out in-place on Wikipedia Commons... -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Multimedia] ogv.js media player update: Flash and GPU acceleration
I've also compared performance to the Cortado Java applet we currently use -- Cortado is still a little faster in terms of CPU usage, but getting the applet to actually *run* with the current version of Java is a nightmare -- even the signed version of the applet from theora.org requires adding a security exception -- whereas JS or Flash just works. For the curious, i looked into the java applet a while back. The reason the caortado applet from theora.ogg doesnt work without a security exception is that they signed it wrong. It needs to be signed and an attribute set saying that it doesnt need extra privs. That attribute isnt set on the theora.ogg version. Even then it still needs a click through prompt. Anyways, great work on all this. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ogv.js media player update: Flash and GPU acceleration
On Sun, Mar 30, 2014 at 09:51:31AM -0700, Brion Vibber wrote: I spent a little more time the last few weekends on ogv.js (JavaScript-based player for Ogg Theora and Vorbis media in IE and Safari) This is just awesome work, Brion and in amazingly little time. I'm really excited to see this. Keep up and let me know if I can help in any way! (e.g. the seeking/Swift/Varnish header stuff) Faidon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal for A system for reviewing funding requests
Hi Gryllida, I am extremely sorry I took so long to reply to your mail, I was down with typhoid and I am slowly recovering. I made corrections as you suggested. Thanks a lot for sparing your time. As instructed by you I included my full opensource contribution history and just for the record I am stating it here as well. I have four bug patches merged from last year. bug 45580https://bugzilla.wikimedia.org/show_bug.cgi?id=45580 , bug 43504 https://bugzilla.wikimedia.org/show_bug.cgi?id=43504, bug 33438 https://bugzilla.wikimedia.org/show_bug.cgi?id=33438 bug 48197 https://bugzilla.wikimedia.org/show_bug.cgi?id=48197 This year due to my ill health I could only get two in. https://gerrit.wikimedia.org/r/117854 https://gerrit.wikimedia.org/r/121975 The last patch is relavant to my gsoc project as it deals with forms which is kind of a part of the project that I applied to. I would see to that these two get merged as well and if possible I will send one more over the next weekend. The only other open source project that I have contributed to is PHPMYADMIN which has very high standards for patch acceptance and stringent code reviews. I have four patches merged in there as well. Of these one of those is 280 line patch that I talked about in my proposal as well. The details of the rest of the patches could be found here: https://github.com/phpmyadmin/phpmyadmin/commits?author=ganeshaditya1 Regards, Aditya ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Caching with Varnish
Thanks for the responses guys. We'll take this into consideration for future development and testing. --Shawn On 3/29/14, 12:59 AM, Liangent wrote: No they were deliberately made not cached because otherwise in the event that some sensitive data got oversighted, they may still keep accessible from cached data, and there are even no way to have them go away. On Mar 29, 2014 11:40 AM, Brian Wolff bawo...@gmail.com wrote: On 3/28/14, Shawn Jones sj...@cs.odu.edu wrote: Hi, As part of our extension testing, we've set up varnish in accordance with http://www.mediawiki.org/wiki/Manual:Varnish_caching One of the things we've noticed is that our oldid URIs are cached, whereas Wikipedia doesn't seem to cache those pages. Is there a reason why Wikipedia doesn't do this? Is there some threshold that Wikipedia uses for caching? Thanks in advance, Shawn M. Jones Graduate Research Assistant Department of Computer Science Old Dominion University ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I think your caching is set up incorrectly. MediaWiki does not (afaik) send an smaxage caching header for requests with an oldid in them. See the $output-setSquidMaxage( $wgSquidMaxage ); line in MediaWiki::performAction (line 425 of includes/Wiki.php). The caching headers are only sent if the url is in the list of urls that can be purged (basically normal page views and history page views). If other pages are being cached, it probably means all pages are being cached for you, which is not a good thing and will cause problems, since there are some pages that really should not be cached. In the case of oldid urls, it may make sense for us to send caching headers with oldid urls, since they do not change (excluding of course oldid's that don't exist) --bawolff ___ 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 -- Shawn M. Jones Graduate Research Assistant Department of Computer Science Old Dominion University ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for March 24, 2014 - March 31, 2014
Status changes this week
Reports changed/set to UNCONFIRMED: 5
Reports changed/set to NEW: 17
Reports changed/set to ASSIGNED : 20
Reports changed/set to REOPENED : 10
Reports changed/set to PATCH_TO_RE: 80
Reports changed/set to RESOLVED : 237
Reports changed/set to VERIFIED : 4
Total reports still open : 14191
Total bugs still open : 8371
Total non-lowest prio. bugs still open: 8157
Total enhancements still open : 5820
Reports created this week: 297
Resolutions for the week:
Reports marked FIXED : 178
Reports marked DUPLICATE : 23
Reports marked INVALID : 14
Reports marked WORKSFORME: 10
Reports marked WONTFIX : 7
Specific Product/Component Resolutions User Metrics
Created reports per component
MediaWiki extensions WikidataRepo 27
VisualEditor Editing Tools 27
MediaWiki extensions Popups17
Wikimedia Continuous integration10
VisualEditor General 10
Created reports per product
MediaWiki extensions 111
VisualEditor 49
Wikimedia 36
MediaWiki 32
Wikimedia Labs17
Top 5 bug report closers
jforrester [AT] wikimedia.org 26
jeroen_dedauw [AT] yahoo.com 25
marc [AT] uberbox.org 19
tobias.gritschacher [AT] wikim14
hoo [AT] online.de12
Most urgent open issues
Product | Component | BugID | Priority | LastChange | Assignee
| Summary
--
MediaWiki | Database | 32551 | Highest | 2014-03-25 |
gdubuc[AT]wikimedia. | Descriptionless files (Missing page_l
MediaWiki | Special pages | 63249 | Highest | 2014-03-29 |
wikibugs-l[AT]lists. | Uncacheable RecentChanges feed, outli
MediaWiki ext | CirrusSearch | 62077 | Highest | 2014-03-13 |
wikibugs-l[AT]lists. | CirrusSearch: Add monitoring for slo
MediaWiki ext | Echo | 53569 | Highest | 2014-03-25 |
wikibugs-l[AT]lists. | [Regression] Echo: Sending 2 e-mails
MediaWiki ext | Flow | 58016 | Highest | 2014-03-27 |
wikibugs-l[AT]lists. | Flow: Suppression redacts the wrong u
MediaWiki ext | OAuth | 57336 | Highest | 2014-03-26 |
wikibugs-l[AT]lists. | Make metawiki the central OAuth wiki
MediaWiki ext | WikidataRepo | 62425 | Immediate | 2014-03-25 |
wikidata-bugs[AT]lis | wbeditentity permits claim property t
MediaWiki ext | WikidataRepo | 63101 | Highest | 2014-03-26 |
wikidata-bugs[AT]lis | New reference disappears after cancel
MediaWiki ext | WikidataRepo | 63114 | Highest | 2014-03-28 |
wikidata-bugs[AT]lis | prevent adding statements with mismat
MediaWiki ext | WikidataRepo | 63223 | Highest | 2014-03-28 |
wikidata-bugs[AT]lis | review frontend part of entity sugges
MediaWiki ext | WikidataRepo | 63224 | Highest | 2014-03-28 |
wikidata-bugs[AT]lis | review backend part of entity suggest
MediaWiki ext | WikidataRepo | 63228 | Highest | 2014-03-28 |
wikidata-bugs[AT]lis | prevent import of items
MediaWiki ext | WikidataRepo | 52385 | Highest | 2014-03-28 |
wikidata-bugs[AT]lis | Query by one property and one value (
MediaWiki ext | WikidataRepo | 63255 | Highest | 2014-03-29 |
wikidata-bugs[AT]lis | check standard spam prevention featur
MobileFronten | General/Unkno | 63248 | Highest | 2014-03-29 |
wikibugs-l[AT]lists. | search pageimages feature causes sign
Wikimedia | Mailing lists | 59731 | Highest | 2014-03-21 |
wikibugs-l[AT]lists. | mailman emails taking long time for d
Wikimedia Lab | Infrastructur | 48501 | Highest | 2014-02-21 |
greg[AT]wikimedia.or | beta: Get SSL certificates for *.{pro
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
