HTML templating systems & MediaWiki - is this summary right?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

HTML templating systems & MediaWiki - is this summary right?

Sumana Harihareswara-2
I'm trying to understand what our current situation is and what our
choices are around HTML templating systems and MediaWiki, so I'm gonna
note what I think I understand so far in this mail and then would love
for people to correct me. TL;DR - did we already consense on a
templating system and I just missed it?

Description: An HTML templates system (also known as a templating
engine) lets you (the programmer) write something that looks more like a
document than it looks like code, then has hooks/entry points/macro
substitution points (for user input and whatnot) that then invoke code,
then emits finished HTML for the browser to render.

Examples: PHP itself is kinda a templating language. In the PHP world,
Smarty is a somewhat more mature/old-school choice. Mustache.js is a
popular modern choice. And in other languages, you'd pick a lot of the
MVC frameworks that are popular, e.g. Django or Jinja in Python.

Spectrum of approaches: One approach treats HTML as a string ("here's a
bunch of bytes to interpolate"). From a security perspective, this is
dangerously easy to have vulnerabilities in, because you just naively
insert strings. Then on the other end of the spectrum, you have code
that always keeps the document object model (DOM) in memory, so the
programmer is abstractly manipulating that data model and passing around
an object. Sure, it spits out HTML in the end, but inherent in the
method for turning those objects into HTML is a sanitization step, so
that's inherently more secure. There's some discussion at
https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates . I
presume we want the latter, but that the former model is more performant?

We talked about this stuff in
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
and
https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
. Based on that plus
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
it seems like we are supposed to get consensus on which system(s) to
use, and we kind of have four things we could choose:

* oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
toolkit with one of the template approaches below, or maybe this is
enough by itself! Currently used inside VisualEditor and I am not sure
whether any other MediaWiki extensions or teams are using it? This is a
DOM-based templating system.

Template approaches which are competing?:
* MVC framework - Wikia has written their own templating library that
Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
RFC review meeting.
https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
* mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I think?
* Knockout-compatible implementation in Node.js & PHP
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
and
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
, being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.

There's also an OutputPage refactor suggested in
https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
that's part of the HTML Templating RFC Cluster
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
.

I guess my biggest question right now is whether I have all the big
moving parts right in my summary above. Thanks.

--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Peter Kaminski
Hi Sumana,

I think a key concept you might want to capture is "separation of
concerns" -- a templating engine allows separation of presentation logic
from business logic.  Often, the two are handled by different people
with different skills, in service of separate goals.  So having the
templating engine specialized for presentation logic is important.

The point isn't so much that the templates look like a document, as much
as they can be written in a simplified language that's specialized for
outputting documents.

Also, I don't know if these are useful in this context, but I wanted to
point to two of the cutting-edge template engines from the PHP
frameworks world, as representatives of modern PHP template thinking:

Fabien Potencier's Twig
http://twig.sensiolabs.org/

Laravel's Blade
http://laravel.com/docs/templates#blade-templating
http://culttt.com/2013/09/02/using-blade-laravel-4/

Neither of these, though, are oriented to dual JavaScript/PHP support,
which I think is an interesting path to consider.

And last, two Wikipedia pages that might be relevant:

https://en.wikipedia.org/wiki/Web_template_system
https://en.wikipedia.org/wiki/Comparison_of_web_template_engines

Pete

On 3/18/14, 20:27 PM, Sumana Harihareswara wrote:

> I'm trying to understand what our current situation is and what our
> choices are around HTML templating systems and MediaWiki, so I'm gonna
> note what I think I understand so far in this mail and then would love
> for people to correct me. TL;DR - did we already consense on a
> templating system and I just missed it?
>
> Description: An HTML templates system (also known as a templating
> engine) lets you (the programmer) write something that looks more like a
> document than it looks like code, then has hooks/entry points/macro
> substitution points (for user input and whatnot) that then invoke code,
> then emits finished HTML for the browser to render.
>
> Examples: PHP itself is kinda a templating language. In the PHP world,
> Smarty is a somewhat more mature/old-school choice. Mustache.js is a
> popular modern choice. And in other languages, you'd pick a lot of the
> MVC frameworks that are popular, e.g. Django or Jinja in Python.
>
> Spectrum of approaches: One approach treats HTML as a string ("here's a
> bunch of bytes to interpolate"). From a security perspective, this is
> dangerously easy to have vulnerabilities in, because you just naively
> insert strings. Then on the other end of the spectrum, you have code
> that always keeps the document object model (DOM) in memory, so the
> programmer is abstractly manipulating that data model and passing around
> an object. Sure, it spits out HTML in the end, but inherent in the
> method for turning those objects into HTML is a sanitization step, so
> that's inherently more secure. There's some discussion at
> https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates . I
> presume we want the latter, but that the former model is more performant?
>
> We talked about this stuff in
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
> and
> https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
> . Based on that plus
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> it seems like we are supposed to get consensus on which system(s) to
> use, and we kind of have four things we could choose:
>
> * oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
> toolkit with one of the template approaches below, or maybe this is
> enough by itself! Currently used inside VisualEditor and I am not sure
> whether any other MediaWiki extensions or teams are using it? This is a
> DOM-based templating system.
>
> Template approaches which are competing?:
> * MVC framework - Wikia has written their own templating library that
> Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
> RFC review meeting.
> https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
> * mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I think?
> * Knockout-compatible implementation in Node.js & PHP
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
> and
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
> , being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.
>
> There's also an OutputPage refactor suggested in
> https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
> that's part of the HTML Templating RFC Cluster
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> .
>
> I guess my biggest question right now is whether I have all the big
> moving parts right in my summary above. Thanks.
>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Dmitriy Sintsov-2
On 19.03.2014 12:10, Peter Kaminski wrote:

> Hi Sumana,
>
> I think a key concept you might want to capture is "separation of
> concerns" -- a templating engine allows separation of presentation
> logic from business logic.  Often, the two are handled by different
> people with different skills, in service of separate goals.  So having
> the templating engine specialized for presentation logic is important.
>
> The point isn't so much that the templates look like a document, as
> much as they can be written in a simplified language that's
> specialized for outputting documents.
>
> Also, I don't know if these are useful in this context, but I wanted
> to point to two of the cutting-edge template engines from the PHP
> frameworks world, as representatives of modern PHP template thinking:
>
> Fabien Potencier's Twig
> http://twig.sensiolabs.org/
>
> Laravel's Blade
> http://laravel.com/docs/templates#blade-templating
> http://culttt.com/2013/09/02/using-blade-laravel-4/
>
> Neither of these, though, are oriented to dual JavaScript/PHP support,
> which I think is an interesting path to consider.
>
> And last, two Wikipedia pages that might be relevant:
>
> https://en.wikipedia.org/wiki/Web_template_system
> https://en.wikipedia.org/wiki/Comparison_of_web_template_engines
>
> Pete
>
MediaWiki Parser itself could be used for skinning as well with some
features disabled.
But actually just associative nested arrays are good enough as template
engine, which are used for example in Drupal:
https://drupal.org/node/930760

|// New method of generating the render array and returning that
function mymodule_ra_page() {
$output =  array(
'first_para' => array(
'#type' => 'markup',
'#markup' => '<p>A paragraph about some stuff...</p>',
     ),
'second_para' => array(
'#items' => array('first item', 'second item', 'third item'),
'#theme' => 'item_list',
     ),
   );
   return $output;
}|

Each key of such associative array can be mapped to view method, while
it's values are view parameters (properties). Quite flexible, fast and
powerful approach which also allows to late manipulation of Output.
Dmitriy

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Chris Steipp
In reply to this post by Sumana Harihareswara-2
On Tue, Mar 18, 2014 at 8:27 PM, Sumana Harihareswara <[hidden email]
> wrote:

> I'm trying to understand what our current situation is and what our
> choices are around HTML templating systems and MediaWiki, so I'm gonna
> note what I think I understand so far in this mail and then would love
> for people to correct me. TL;DR - did we already consense on a
> templating system and I just missed it?
>
> Description: An HTML templates system (also known as a templating
> engine) lets you (the programmer) write something that looks more like a
> document than it looks like code, then has hooks/entry points/macro
> substitution points (for user input and whatnot) that then invoke code,
> then emits finished HTML for the browser to render.
>
> Examples: PHP itself is kinda a templating language. In the PHP world,
> Smarty is a somewhat more mature/old-school choice. Mustache.js is a
> popular modern choice. And in other languages, you'd pick a lot of the
> MVC frameworks that are popular, e.g. Django or Jinja in Python.
>
> Spectrum of approaches: One approach treats HTML as a string ("here's a
> bunch of bytes to interpolate"). From a security perspective, this is
> dangerously easy to have vulnerabilities in, because you just naively
> insert strings. Then on the other end of the spectrum, you have code
> that always keeps the document object model (DOM) in memory, so the
> programmer is abstractly manipulating that data model and passing around
> an object. Sure, it spits out HTML in the end, but inherent in the
> method for turning those objects into HTML is a sanitization step, so
> that's inherently more secure. There's some discussion at
> https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates . I
> presume we want the latter, but that the former model is more performant?
>

I don't want to build too much of a straw man against string-based systems,
so it's probably more appropriate to say that the same escaping is applied
to all strings regardless of the html context, or the developer is
responsible for applying custom escaping. So for string-based systems to be
as safe as dom ones, we also need a layer of policy and code review that we
might not need with a dom-based system.

Performance of the dom-based systems has turned out to be not that bad, but
performance is a major factor in any engine we go with.



>
> We talked about this stuff in
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
> and
>
> https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
> . Based on that plus
>
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> it seems like we are supposed to get consensus on which system(s) to
> use, and we kind of have four things we could choose:
>
> * oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
> toolkit with one of the template approaches below, or maybe this is
> enough by itself! Currently used inside VisualEditor and I am not sure
> whether any other MediaWiki extensions or teams are using it? This is a
> DOM-based templating system.
>
> Template approaches which are competing?:
> * MVC framework - Wikia has written their own templating library that
> Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
> RFC review meeting.
> https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
> * mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I think?
> * Knockout-compatible implementation in Node.js & PHP
>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
> and
>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
> , being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.
>


I think
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_librarycaptures
most of the current thinking. While Knockoff is being developed,
Handlebars (and the php port of it) seems to be the leader for a
string-based solution.


>
> There's also an OutputPage refactor suggested in
> https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
> that's part of the HTML Templating RFC Cluster
>
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> .
>
> I guess my biggest question right now is whether I have all the big
> moving parts right in my summary above. Thanks.


> --
> Sumana Harihareswara
> Senior Technical Writer
> Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Gabriel Wicke-3
In reply to this post by Sumana Harihareswara-2
We made some good progress on KnockOff [1,2] recently. It is currently the
fastest library in our micro benchmarks [3] despite having a DOM-based
compiler with the associated security advantages. Matt has started work on
the PHP port before going on vacation, but I expect that we'll have a PHP
runtime next week as well. The runtime code is still small at 337 lines.

Cheers,

Gabriel

[1]:
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
[2]: https://github.com/gwicke/knockoff
[3]:
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Nuria Ruiz
In reply to this post by Chris Steipp
>So for string-based systems to be
>as safe as dom ones, we also need a layer of policy and code review that we
>might not need with a dom-based system.
String based template engines (like handlebars) do escape as a default, you
have to use "special" markup for it not to escape. Can you explain in more
detail what is the security concern with those?





On Wed, Mar 19, 2014 at 7:51 PM, Chris Steipp <[hidden email]> wrote:

> On Tue, Mar 18, 2014 at 8:27 PM, Sumana Harihareswara <
> [hidden email]
> > wrote:
>
> > I'm trying to understand what our current situation is and what our
> > choices are around HTML templating systems and MediaWiki, so I'm gonna
> > note what I think I understand so far in this mail and then would love
> > for people to correct me. TL;DR - did we already consense on a
> > templating system and I just missed it?
> >
> > Description: An HTML templates system (also known as a templating
> > engine) lets you (the programmer) write something that looks more like a
> > document than it looks like code, then has hooks/entry points/macro
> > substitution points (for user input and whatnot) that then invoke code,
> > then emits finished HTML for the browser to render.
> >
> > Examples: PHP itself is kinda a templating language. In the PHP world,
> > Smarty is a somewhat more mature/old-school choice. Mustache.js is a
> > popular modern choice. And in other languages, you'd pick a lot of the
> > MVC frameworks that are popular, e.g. Django or Jinja in Python.
> >
> > Spectrum of approaches: One approach treats HTML as a string ("here's a
> > bunch of bytes to interpolate"). From a security perspective, this is
> > dangerously easy to have vulnerabilities in, because you just naively
> > insert strings. Then on the other end of the spectrum, you have code
> > that always keeps the document object model (DOM) in memory, so the
> > programmer is abstractly manipulating that data model and passing around
> > an object. Sure, it spits out HTML in the end, but inherent in the
> > method for turning those objects into HTML is a sanitization step, so
> > that's inherently more secure. There's some discussion at
> > https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates . I
> > presume we want the latter, but that the former model is more performant?
> >
>
> I don't want to build too much of a straw man against string-based systems,
> so it's probably more appropriate to say that the same escaping is applied
> to all strings regardless of the html context, or the developer is
> responsible for applying custom escaping. So for string-based systems to be
> as safe as dom ones, we also need a layer of policy and code review that we
> might not need with a dom-based system.
>
> Performance of the dom-based systems has turned out to be not that bad, but
> performance is a major factor in any engine we go with.
>
>
>
> >
> > We talked about this stuff in
> >
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
> > and
> >
> >
> https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
> > . Based on that plus
> >
> >
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> > it seems like we are supposed to get consensus on which system(s) to
> > use, and we kind of have four things we could choose:
> >
> > * oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
> > toolkit with one of the template approaches below, or maybe this is
> > enough by itself! Currently used inside VisualEditor and I am not sure
> > whether any other MediaWiki extensions or teams are using it? This is a
> > DOM-based templating system.
> >
> > Template approaches which are competing?:
> > * MVC framework - Wikia has written their own templating library that
> > Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
> > RFC review meeting.
> > https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
> > * mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I
> think?
> > * Knockout-compatible implementation in Node.js & PHP
> >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
> > and
> >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
> > , being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.
> >
>
>
> I think
>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_librarycaptures
> most of the current thinking. While Knockoff is being developed,
> Handlebars (and the php port of it) seems to be the leader for a
> string-based solution.
>
>
> >
> > There's also an OutputPage refactor suggested in
> > https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
> > that's part of the HTML Templating RFC Cluster
> >
> >
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> > .
> >
> > I guess my biggest question right now is whether I have all the big
> > moving parts right in my summary above. Thanks.
>
>
> > --
> > Sumana Harihareswara
> > Senior Technical Writer
> > Wikimedia Foundation
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Nuria Ruiz
In reply to this post by Sumana Harihareswara-2
Sumana,

Sorry for my late reply but since you asked for corrections, here are a
couple.

>Mustache.js is a popular modern choice.
Not really, mustache has many lack-offs that prevent it from being a
popular choice, among them the lack of a server side compiler and if/else
constructs. Handlebars is a lot more popular. Also twitters flavor of a
string based engine: http://twitter.github.io/hogan.js/


>One approach treats HTML as a string ("here's a
>bunch of bytes to interpolate"). From a security perspective, this is
>dangerously easy to have vulnerabilities in, because you just naively
>insert strings.
This is not correct. String based systems escape the strings they are
interpolating by default.
Take a look at escaping of what is the most popular string-based engine,
handlebars: https://github.com/wycats/handlebars.js/




On Wed, Mar 19, 2014 at 4:27 AM, Sumana Harihareswara <[hidden email]
> wrote:

> I'm trying to understand what our current situation is and what our
> choices are around HTML templating systems and MediaWiki, so I'm gonna
> note what I think I understand so far in this mail and then would love
> for people to correct me. TL;DR - did we already consense on a
> templating system and I just missed it?
>
> Description: An HTML templates system (also known as a templating
> engine) lets you (the programmer) write something that looks more like a
> document than it looks like code, then has hooks/entry points/macro
> substitution points (for user input and whatnot) that then invoke code,
> then emits finished HTML for the browser to render.
>
> Examples: PHP itself is kinda a templating language. In the PHP world,
> Smarty is a somewhat more mature/old-school choice. Mustache.js is a
> popular modern choice. And in other languages, you'd pick a lot of the
> MVC frameworks that are popular, e.g. Django or Jinja in Python.
>
> Spectrum of approaches: One approach treats HTML as a string ("here's a
> bunch of bytes to interpolate"). From a security perspective, this is
> dangerously easy to have vulnerabilities in, because you just naively
> insert strings. Then on the other end of the spectrum, you have code
> that always keeps the document object model (DOM) in memory, so the
> programmer is abstractly manipulating that data model and passing around
> an object. Sure, it spits out HTML in the end, but inherent in the
> method for turning those objects into HTML is a sanitization step, so
> that's inherently more secure. There's some discussion at
> https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates . I
> presume we want the latter, but that the former model is more performant?
>
> We talked about this stuff in
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
> and
>
> https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
> . Based on that plus
>
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> it seems like we are supposed to get consensus on which system(s) to
> use, and we kind of have four things we could choose:
>
> * oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
> toolkit with one of the template approaches below, or maybe this is
> enough by itself! Currently used inside VisualEditor and I am not sure
> whether any other MediaWiki extensions or teams are using it? This is a
> DOM-based templating system.
>
> Template approaches which are competing?:
> * MVC framework - Wikia has written their own templating library that
> Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
> RFC review meeting.
> https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
> * mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I think?
> * Knockout-compatible implementation in Node.js & PHP
>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
> and
>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
> , being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.
>
> There's also an OutputPage refactor suggested in
> https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
> that's part of the HTML Templating RFC Cluster
>
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> .
>
> I guess my biggest question right now is whether I have all the big
> moving parts right in my summary above. Thanks.
>
> --
> Sumana Harihareswara
> Senior Technical Writer
> Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Chris Steipp
In reply to this post by Nuria Ruiz
On Wed, Mar 26, 2014 at 3:21 AM, Nuria Ruiz <[hidden email]> wrote:

> >So for string-based systems to be
> >as safe as dom ones, we also need a layer of policy and code review that
> we
> >might not need with a dom-based system.
> String based template engines (like handlebars) do escape as a default, you
> have to use "special" markup for it not to escape. Can you explain in more
> detail what is the security concern with those?
>

Correct. 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()". So
policy/code review is needed to say that attributes with user-supplied data
must be quoted in a way compatible with the templating engine (' or " for
Twig, " for Mustache since Mustache doesn't escape single quotes).


>
>
>
>
>
> On Wed, Mar 19, 2014 at 7:51 PM, Chris Steipp <[hidden email]>
> wrote:
>
> > On Tue, Mar 18, 2014 at 8:27 PM, Sumana Harihareswara <
> > [hidden email]
> > > wrote:
> >
> > > I'm trying to understand what our current situation is and what our
> > > choices are around HTML templating systems and MediaWiki, so I'm gonna
> > > note what I think I understand so far in this mail and then would love
> > > for people to correct me. TL;DR - did we already consense on a
> > > templating system and I just missed it?
> > >
> > > Description: An HTML templates system (also known as a templating
> > > engine) lets you (the programmer) write something that looks more like
> a
> > > document than it looks like code, then has hooks/entry points/macro
> > > substitution points (for user input and whatnot) that then invoke code,
> > > then emits finished HTML for the browser to render.
> > >
> > > Examples: PHP itself is kinda a templating language. In the PHP world,
> > > Smarty is a somewhat more mature/old-school choice. Mustache.js is a
> > > popular modern choice. And in other languages, you'd pick a lot of the
> > > MVC frameworks that are popular, e.g. Django or Jinja in Python.
> > >
> > > Spectrum of approaches: One approach treats HTML as a string ("here's a
> > > bunch of bytes to interpolate"). From a security perspective, this is
> > > dangerously easy to have vulnerabilities in, because you just naively
> > > insert strings. Then on the other end of the spectrum, you have code
> > > that always keeps the document object model (DOM) in memory, so the
> > > programmer is abstractly manipulating that data model and passing
> around
> > > an object. Sure, it spits out HTML in the end, but inherent in the
> > > method for turning those objects into HTML is a sanitization step, so
> > > that's inherently more secure. There's some discussion at
> > > https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates .
> I
> > > presume we want the latter, but that the former model is more
> performant?
> > >
> >
> > I don't want to build too much of a straw man against string-based
> systems,
> > so it's probably more appropriate to say that the same escaping is
> applied
> > to all strings regardless of the html context, or the developer is
> > responsible for applying custom escaping. So for string-based systems to
> be
> > as safe as dom ones, we also need a layer of policy and code review that
> we
> > might not need with a dom-based system.
> >
> > Performance of the dom-based systems has turned out to be not that bad,
> but
> > performance is a major factor in any engine we go with.
> >
> >
> >
> > >
> > > We talked about this stuff in
> > >
> >
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
> > > and
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
> > > . Based on that plus
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> > > it seems like we are supposed to get consensus on which system(s) to
> > > use, and we kind of have four things we could choose:
> > >
> > > * oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
> > > toolkit with one of the template approaches below, or maybe this is
> > > enough by itself! Currently used inside VisualEditor and I am not sure
> > > whether any other MediaWiki extensions or teams are using it? This is a
> > > DOM-based templating system.
> > >
> > > Template approaches which are competing?:
> > > * MVC framework - Wikia has written their own templating library that
> > > Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
> > > RFC review meeting.
> > > https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
> > > * mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I
> > think?
> > > * Knockout-compatible implementation in Node.js & PHP
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
> > > and
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
> > > , being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.
> > >
> >
> >
> > I think
> >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_librarycaptures
> > most of the current thinking. While Knockoff is being developed,
> > Handlebars (and the php port of it) seems to be the leader for a
> > string-based solution.
> >
> >
> > >
> > > There's also an OutputPage refactor suggested in
> > >
> https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
> > > that's part of the HTML Templating RFC Cluster
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> > > .
> > >
> > > I guess my biggest question right now is whether I have all the big
> > > moving parts right in my summary above. Thanks.
> >
> >
> > > --
> > > Sumana Harihareswara
> > > Senior Technical Writer
> > > Wikimedia Foundation
> > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Nuria Ruiz
>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.

This is equivalent to what we would need to do in PHP
server side if we used PHP native templating.
We would need to implement an escaping function like "makeStringSafe" that
we would execute like:

<div class="View::makeStringSafe($this->something)"></div>

What I wanted to clarify (regarding Sumana's first e-mail) is that when it
comes to security we would need to take the same precautions with a string
based javascript engine than we would do with any PHP engine we choose.
Namely, as you said, spot the lack of "makestringSafe" via CRs.

To be completely fair, the "makeStringSafe" could be inserted with a
build/template compilation process and thus we would not need CRs but
rather we could rely on automation.













On Wed, Mar 26, 2014 at 2:43 PM, Chris Steipp <[hidden email]> wrote:

> On Wed, Mar 26, 2014 at 3:21 AM, Nuria Ruiz <[hidden email]> wrote:
>
> > >So for string-based systems to be
> > >as safe as dom ones, we also need a layer of policy and code review that
> > we
> > >might not need with a dom-based system.
> > String based template engines (like handlebars) do escape as a default,
> you
> > have to use "special" markup for it not to escape. Can you explain in
> more
> > detail what is the security concern with those?
> >
>
> Correct. 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()". So
> policy/code review is needed to say that attributes with user-supplied data
> must be quoted in a way compatible with the templating engine (' or " for
> Twig, " for Mustache since Mustache doesn't escape single quotes).
>
>
> >
> >
> >
> >
> >
> > On Wed, Mar 19, 2014 at 7:51 PM, Chris Steipp <[hidden email]>
> > wrote:
> >
> > > On Tue, Mar 18, 2014 at 8:27 PM, Sumana Harihareswara <
> > > [hidden email]
> > > > wrote:
> > >
> > > > I'm trying to understand what our current situation is and what our
> > > > choices are around HTML templating systems and MediaWiki, so I'm
> gonna
> > > > note what I think I understand so far in this mail and then would
> love
> > > > for people to correct me. TL;DR - did we already consense on a
> > > > templating system and I just missed it?
> > > >
> > > > Description: An HTML templates system (also known as a templating
> > > > engine) lets you (the programmer) write something that looks more
> like
> > a
> > > > document than it looks like code, then has hooks/entry points/macro
> > > > substitution points (for user input and whatnot) that then invoke
> code,
> > > > then emits finished HTML for the browser to render.
> > > >
> > > > Examples: PHP itself is kinda a templating language. In the PHP
> world,
> > > > Smarty is a somewhat more mature/old-school choice. Mustache.js is a
> > > > popular modern choice. And in other languages, you'd pick a lot of
> the
> > > > MVC frameworks that are popular, e.g. Django or Jinja in Python.
> > > >
> > > > Spectrum of approaches: One approach treats HTML as a string
> ("here's a
> > > > bunch of bytes to interpolate"). From a security perspective, this is
> > > > dangerously easy to have vulnerabilities in, because you just naively
> > > > insert strings. Then on the other end of the spectrum, you have code
> > > > that always keeps the document object model (DOM) in memory, so the
> > > > programmer is abstractly manipulating that data model and passing
> > around
> > > > an object. Sure, it spits out HTML in the end, but inherent in the
> > > > method for turning those objects into HTML is a sanitization step, so
> > > > that's inherently more secure. There's some discussion at
> > > > https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates.
> > I
> > > > presume we want the latter, but that the former model is more
> > performant?
> > > >
> > >
> > > I don't want to build too much of a straw man against string-based
> > systems,
> > > so it's probably more appropriate to say that the same escaping is
> > applied
> > > to all strings regardless of the html context, or the developer is
> > > responsible for applying custom escaping. So for string-based systems
> to
> > be
> > > as safe as dom ones, we also need a layer of policy and code review
> that
> > we
> > > might not need with a dom-based system.
> > >
> > > Performance of the dom-based systems has turned out to be not that bad,
> > but
> > > performance is a major factor in any engine we go with.
> > >
> > >
> > >
> > > >
> > > > We talked about this stuff in
> > > >
> > >
> >
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
> > > > and
> > > >
> > > >
> > >
> >
> https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
> > > > . Based on that plus
> > > >
> > > >
> > >
> >
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> > > > it seems like we are supposed to get consensus on which system(s) to
> > > > use, and we kind of have four things we could choose:
> > > >
> > > > * oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
> > > > toolkit with one of the template approaches below, or maybe this is
> > > > enough by itself! Currently used inside VisualEditor and I am not
> sure
> > > > whether any other MediaWiki extensions or teams are using it? This
> is a
> > > > DOM-based templating system.
> > > >
> > > > Template approaches which are competing?:
> > > > * MVC framework - Wikia has written their own templating library that
> > > > Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in
> the
> > > > RFC review meeting.
> > > > https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
> > > > * mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I
> > > think?
> > > > * Knockout-compatible implementation in Node.js & PHP
> > > >
> > > >
> > >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
> > > > and
> > > >
> > > >
> > >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
> > > > , being worked on by Gabriel Wicke, Matt Walker, and others.
> DOM-based.
> > > >
> > >
> > >
> > > I think
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_librarycaptures
> > > most of the current thinking. While Knockoff is being developed,
> > > Handlebars (and the php port of it) seems to be the leader for a
> > > string-based solution.
> > >
> > >
> > > >
> > > > There's also an OutputPage refactor suggested in
> > > >
> > https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
> > > > that's part of the HTML Templating RFC Cluster
> > > >
> > > >
> > >
> >
> https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
> > > > .
> > > >
> > > > I guess my biggest question right now is whether I have all the big
> > > > moving parts right in my summary above. Thanks.
> > >
> > >
> > > > --
> > > > Sumana Harihareswara
> > > > Senior Technical Writer
> > > > Wikimedia Foundation
> > > >
> > > > _______________________________________________
> > > > Wikitech-l mailing list
> > > > [hidden email]
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Daniel Friesen-2
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?

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

C. Scott Ananian
Note that my favorite "handlebars-like" template engine is currently
"spacebars", developed as part of the meteor.js project.  This does safe
structured interpolation, so it's not really a "string-based" template
engine any more -- but it still contains the same minimalist markup (it
basically looks identical to handlebars, it's just a new implementation).

I've worked some with gwicke on spacebars support for his templating
project.

The other important aspect which I haven't seen mentioned yet is editor
support.  Where does using the template system fall, on a scale with
"writing an article for humans" on one side and "writing executable code"
on the other?

Even this is not necessarily straightforward to assess.  As I understand
it, one of the advantages of KnockOff is that, although at a raw HTML level
it looks cumbersome for a human to author, it is structured in a way that
would make it easier to integrate with something like Visual Editor, with
simple properties that can be added to sample text to turn it into a
template.

I personally lean toward "handlebars"-style engines, because the extremely
minimalist syntax makes it easy for non-coders to author directly.  A
user-friendly editor for such a template language would probably expose
separate "content" and "code" views of a template.  Basic templates
wouldn't have any code, but advanced templates would use something like
Scribunto for easy editing of the code associated with a template.
 --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Chris Steipp
In reply to this post by Daniel Friesen-2
On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
<[hidden email]>wrote:

> 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
"makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe" 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 class attribute vs the text.



> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
>
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Nuria Ruiz
In reply to this post by Daniel Friesen-2
>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?

Sorry but I think you might have missunderstood Chris' example. Attributes
should not need any quoting, that is not a real use case. Place holders are
replaced by attributes that might be extra-escaped but in any case the
template engine should infer anything as to the content being replaced.

The expected outcome after substitution should be: <div
class=some-escaped-text> </div>








On Wed, Mar 26, 2014 at 5:44 PM, Daniel Friesen
<[hidden email]>wrote:

> 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?
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Daniel Friesen-2
On 2014-03-26, 10:15 AM, Nuria Ruiz wrote:

>> 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?
> Sorry but I think you might have missunderstood Chris' example. Attributes
> should not need any quoting, that is not a real use case. Place holders are
> replaced by attributes that might be extra-escaped but in any case the
> template engine should infer anything as to the content being replaced.
>
> The expected outcome after substitution should be: <div
> class=some-escaped-text> </div>
And Chris explained that if 'something' was 'some-text
onclick=doSomething()' instead of 'some-text' then instead of:

<div class=some-escaped-text> </div>

The template engine would output:

<div class=some-escaped-text onclick=doSomething()> </div>

Creating an XSS vector.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Nuria Ruiz
In reply to this post by Chris Steipp
>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. 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 <[hidden email]> wrote:

> On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
> <[hidden email]>wrote:
>
> > 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
> "makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe" 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 class attribute vs the text.
>
>
>
> > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
> >
> >
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Chris Steipp
On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
> > <[hidden email]>wrote:
> >
> > > 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
> > "makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe" 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 class attribute vs the text.
> >
> >
> >
> > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/
> ]
> > >
> > >
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Chris Steipp
In reply to this post by Nuria Ruiz
On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz <[hidden email]> 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.
>

When looking at a typical web page, you need several escaping strategies.
OWASP roughly groups them into html body, plain attributes, URL context,
Javascript context, CSS context. My point was that you need several
MakeWhateverSafe functions, and have to use them in the right context. So
that is a long way of saying I disagree with you when you said that this
could be automated without some process having knowledge of the html
context and verifying the right escaping is being applied.


>
>
> >$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. 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 <[hidden email]>
> wrote:
>
> > On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
> > <[hidden email]>wrote:
> >
> > > 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
> > "makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe" 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 class attribute vs the text.
> >
> >
> >
> > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/
> ]
> > >
> > >
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Gabriel Wicke-3
On 03/26/2014 10:55 AM, Chris Steipp wrote:

> On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz <[hidden email]> 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.
>>
>
> When looking at a typical web page, you need several escaping strategies.
> OWASP roughly groups them into html body, plain attributes, URL context,
> Javascript context, CSS context. My point was that you need several
> MakeWhateverSafe functions, and have to use them in the right context. So
> that is a long way of saying I disagree with you when you said that this
> could be automated without some process having knowledge of the html
> context and verifying the right escaping is being applied.

When compiling from DOM to the TAssembly JSON IR we encode the attribute
context in the 'attr' binding. While executing this binding TAssembly
automatically escapes href / src and style attributes using the same
sanitization logic as used in Parsoid, which in turn is a direct port of
MediaWiki's Sanitizer.php. Despite offering this level of security support
it is the fastest library in our benchmarks.

KnockOff is compiling to TAssembly from KnockoutJS syntax, but other
front-end syntaxes are possible like cscott's Spacebars to TAssembly
compiler. We chose the KnockoutJS syntax primarily for its ease of
implementation (the expression grammar is 70 lines, and DOM parsing is
readily available). It also supports powerful and general parameter passing
which is useful for things like i18n, and has good potential support for
server-side pre-expansion followed by client-side updates by virtue of its
attribute syntax.

Last night Matt has been back working on the PHP port of TAssembly. We'll
probably have an update on this in the next days.

Gabriel

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Nuria Ruiz
In reply to this post by Chris Steipp
>> <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 <[hidden email]> wrote:

> On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz <[hidden email]> 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 <[hidden email]>
> > wrote:
> >
> > > On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
> > > <[hidden email]>wrote:
> > >
> > > > 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
> > > "makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe"
> 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 class attribute vs the text.
> > >
> > >
> > >
> > > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
> http://danielfriesen.name/
> > ]
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HTML templating systems & MediaWiki - is this summary right?

Tyler Romeo
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 <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz <[hidden email]>
> 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 <[hidden email]>
> > > wrote:
> > >
> > > > On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen
> > > > <[hidden email]>wrote:
> > > >
> > > > > 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
> > > > "makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe"
> > 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 class attribute vs the text.
> > > >
> > > >
> > > >
> > > > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
> > http://danielfriesen.name/
> > > ]
> > > > >
> > > > >
> > > > >
> > > > _______________________________________________
> > > > Wikitech-l mailing list
> > > > [hidden email]
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12