Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Moving MediaWikiWidgets.org to Wikimedia

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


sergey.chernyshev at gmail

Sep 3, 2012, 7:57 PM

Post #1 of 20 (1388 views)
Permalink
Moving MediaWikiWidgets.org to Wikimedia

Hi everybody,

Sumana suggested I should post to this list so you guys can help me.

A few years back I saw a need in easy widget creation and too many
extensions that just did that, but were not so well maintained and had a
bunch of XSS holes in them and so on, that's when I came up with idea of
Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets

Since individual widgets were just wiki pages, I created a standalone wiki
where everybody can post their widgets (in special "Widget" namespace)
which will be available to everyone after basic security review (it
integrates with Flagged Revisions if it's installed):
http://www.mediawikiwidgets.org/

There are plenty of widgets there and quite a few people use the extension
and the widgets on their wikis.

That being said, I moved on to other kind of work and would be happy to
give MediaWikiWidgets.org back to community instead of slowly killing it by
inactivity.
It would be great if Wikimedia Foundation could take this project over and
host it either as standalone site or as part of mediawiki.org - I'll be
happy to assist in moving the catalog and would probably still be curious
enough to contribute a widget or two once in a while.

Best,

Sergey
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel at nadir-seen-fire

Sep 3, 2012, 10:44 PM

Post #2 of 20 (1349 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
<sergey.chernyshev [at] gmail> wrote:

> Hi everybody,
>
> Sumana suggested I should post to this list so you guys can help me.
>
> A few years back I saw a need in easy widget creation and too many
> extensions that just did that, but were not so well maintained and had a
> bunch of XSS holes in them and so on, that's when I came up with idea of
> Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets
>
> Since individual widgets were just wiki pages, I created a standalone
> wiki
> where everybody can post their widgets (in special "Widget" namespace)
> which will be available to everyone after basic security review (it
> integrates with Flagged Revisions if it's installed):
> http://www.mediawikiwidgets.org/
>
> There are plenty of widgets there and quite a few people use the
> extension
> and the widgets on their wikis.
>
> That being said, I moved on to other kind of work and would be happy to
> give MediaWikiWidgets.org back to community instead of slowly killing it
> by
> inactivity.
> It would be great if Wikimedia Foundation could take this project over
> and
> host it either as standalone site or as part of mediawiki.org - I'll be
> happy to assist in moving the catalog and would probably still be curious
> enough to contribute a widget or two once in a while.
>
> Best,
>
> Sergey

I don't really like this idea. I'd prefer it that the Widgets extension
doesn't get any more popular than it already is.

Frankly I wish I could stick an {{XSS alert}} template on that page and be
done with it. But I haven't because the extension is only an enabler
making it trivially easy to add an XSS hole into your wiki.

The premise of the extension is flawed. If someone cannot be trusted to
securely write a widget in PHP there is no way that they can be trusted to
properly escape raw concatenated html.
It basically takes extension code; Something we can put into standard
repositories. Provide full pre-commit security review. Notify users of
security holes. And in the future incorporate systems to tell you when
there's a new version (likely with a security fix) you should upgrade to;
And puts it into raw concatenated html wiki pages -- lacking in extensive
escaping and high-level abstraction -- managed by users who do not
necessarily have any programming skills much less a proper understanding
of security. Somewhere developers naturally pay no attention to. Somewhere
with no alerts about security holes, etc... And suggests that users just
C&P the Widget (potentially with an open XSS vector) into their wiki and
never look back to see if a critical hole has been fixed.

A number of widgets inside that site have critical XSS vectors inside of
them. Every time I go back there and look at random ones it doesn't take
long to find a hole.

I would not be opposed to an extension that makes high-level validation
and construction of simple widgets as extension code easier. Or making it
easier to get into Gerrit so people can submit extension code and we can
properly review it.
But there is absolutely no way that the fundamentals the Widgets extension
are based on will provide the proper environment to create secure widgets.

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


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


clement at seizam

Sep 4, 2012, 2:25 AM

Post #3 of 20 (1346 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

>
> On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
> <sergey.chernyshev [at] gmail> wrote:
>
> > Hi everybody,
> >
> > A few years back I saw a need in easy widget creation and too many
> > extensions that just did that, but were not so well maintained and had a
> > bunch of XSS holes in them and so on, that's when I came up with idea of
> > Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets


A very useful extension, enabling quick integration of external services.
Thanks for creating it.

> Since individual widgets were just wiki pages, I created a standalone
> > wiki
> > where everybody can post their widgets (in special "Widget" namespace)
> > which will be available to everyone after basic security review (it
> > integrates with Flagged Revisions if it's installed):
> > http://www.mediawikiwidgets.org/


A very useful website, but sadly dying slowly, as you said. I hope we'll
find a solution to save it.

> Best,
> >
> > Sergey
>
> I don't really like this idea. I'd prefer it that the Widgets extension
> doesn't get any more popular than it already is.
>
> Frankly I wish I could stick an {{XSS alert}} template on that page and be
> done with it. But I haven't because the extension is only an enabler
> making it trivially easy to add an XSS hole into your wiki.
>

Yes, the use of the smarty language within pages, IF misused, can be
dangerous.

The premise of the extension is flawed. If someone cannot be trusted to
> securely write a widget in PHP there is no way that they can be trusted to
> properly escape raw concatenated html.
>

Yes, someone writing a widget through the wiki with this extension must be
trusted.
BUT not as trusted as someone writing a regular php extension
(There is no backend vulnerability)
AND, it's easier and faster to do it through the wiki.


> It basically takes extension code; Something we can put into standard
> repositories. Provide full pre-commit security review. Notify users of
> security holes. And in the future incorporate systems to tell you when
> there's a new version (likely with a security fix) you should upgrade to;
> And puts it into raw concatenated html wiki pages -- lacking in extensive
> escaping and high-level abstraction -- managed by users who do not
> necessarily have any programming skills much less a proper understanding
> of security. Somewhere developers naturally pay no attention to. Somewhere
> with no alerts about security holes, etc... And suggests that users just
> C&P the Widget (potentially with an open XSS vector) into their wiki and
> never look back to see if a critical hole has been fixed.
>

True, there are more secure and synchronized ways to go.

A number of widgets inside that site have critical XSS vectors inside of
> them. Every time I go back there and look at random ones it doesn't take
> long to find a hole.


I use widgets a lot and never found such holes (but I mainly use very
popular ones).
Can you please give an example? I'm afraid there could be flaws I did not
see...

I would not be opposed to an extension that makes high-level validation
> and construction of simple widgets as extension code easier. Or making it
> easier to get into Gerrit so people can submit extension code and we can
> properly review it.
>

I do think this is a great idea.
A "widget framework" extension that ease the development of widgets
(sub)extensions.
That would both provide the security and the ease of use.
The only remaining problem being that a full release would be necessary to
roll out widgets.
I was actually planning to work on that before the end of the year as a way
to replace the widget extension.
(the extension is useful, but not perfect)


> But there is absolutely no way that the fundamentals the Widgets extension
> are based on will provide the proper environment to create secure widgets.
>

Maybe the widgets extension is not secure, but can we nevertheless imagine
a way to write widgets code in pages?
Lua will certainly be able to handle the logic that smarty does now.
We're just missing a way (for sysops) to override the parser escaping of
<script>, <iframe>, <img>...


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

To me, there is no doubt that (wiki) websites must nowadays be able to
interact with and embed the other services their users love.
The logic necessary to render such external services is very basic and easy.
I do believe that the easiest it is to contribute, the more contribution
you get.
(Just look at the great amount of resources there is on
mwwidgets.orgcompared to
mw.org).

Saving Extension:Widgets,
or building a better extension based on the same in-page code concept,
is worth a try.

--
Clment Dietschy
*Seizam* Srl.
24, rue de Ble
68300 Saint-Louis (France)
tl. +33 6 87 75 99 27
www.seizam.com
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel at nadir-seen-fire

Sep 4, 2012, 3:28 AM

Post #4 of 20 (1356 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, 04 Sep 2012 02:25:56 -0700, Clément Dietschy <clement [at] seizam>
wrote:

>>
>> On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
>> <sergey.chernyshev [at] gmail> wrote:
>>
>> > Hi everybody,
>> >
>> > A few years back I saw a need in easy widget creation and too many
>> > extensions that just did that, but were not so well maintained and
>> had a
>> > bunch of XSS holes in them and so on, that's when I came up with idea
>> of
>> > Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets
>
>
> A very useful extension, enabling quick integration of external services.
> Thanks for creating it.
>
>> Since individual widgets were just wiki pages, I created a standalone
>> > wiki
>> > where everybody can post their widgets (in special "Widget" namespace)
>> > which will be available to everyone after basic security review (it
>> > integrates with Flagged Revisions if it's installed):
>> > http://www.mediawikiwidgets.org/
>
>
> A very useful website, but sadly dying slowly, as you said. I hope we'll
> find a solution to save it.
>
>> Best,
>> >
>> > Sergey
>>
>> I don't really like this idea. I'd prefer it that the Widgets extension
>> doesn't get any more popular than it already is.
>>
>> Frankly I wish I could stick an {{XSS alert}} template on that page and
>> be
>> done with it. But I haven't because the extension is only an enabler
>> making it trivially easy to add an XSS hole into your wiki.
>>
>
> Yes, the use of the smarty language within pages, IF misused, can be
> dangerous.

The larger danger is the people not misusing it. It's way to easy to write
something the wrong way and open yourself up to attack.

> The premise of the extension is flawed. If someone cannot be trusted to
>> securely write a widget in PHP there is no way that they can be trusted
>> to
>> properly escape raw concatenated html.
>>
>
> Yes, someone writing a widget through the wiki with this extension must
> be
> trusted.
> BUT not as trusted as someone writing a regular php extension
> (There is no backend vulnerability)
> AND, it's easier and faster to do it through the wiki.
>
>
>> It basically takes extension code; Something we can put into standard
>> repositories. Provide full pre-commit security review. Notify users of
>> security holes. And in the future incorporate systems to tell you when
>> there's a new version (likely with a security fix) you should upgrade
>> to;
>> And puts it into raw concatenated html wiki pages -- lacking in
>> extensive
>> escaping and high-level abstraction -- managed by users who do not
>> necessarily have any programming skills much less a proper understanding
>> of security. Somewhere developers naturally pay no attention to.
>> Somewhere
>> with no alerts about security holes, etc... And suggests that users just
>> C&P the Widget (potentially with an open XSS vector) into their wiki and
>> never look back to see if a critical hole has been fixed.
>>
>
> True, there are more secure and synchronized ways to go.
>
> A number of widgets inside that site have critical XSS vectors inside of
>> them. Every time I go back there and look at random ones it doesn't take
>> long to find a hole.
>
>
> I use widgets a lot and never found such holes (but I mainly use very
> popular ones).
> Can you please give an example? I'm afraid there could be flaws I did not
> see...

Let's see... Going from A-Z in groups. Just doing some of the widgets at
the start of the list.

The following have full on script execution vulnerabilities based on
tricks that can bypass the escaping used:
Widget:AddThis
Widget:DISQUS
Widget:Feed
Widget:Google Books
Widget:Google Maps
Widget:Google Street View

The following have CSS based injection vulnerabilities (this is full on
script injection in some browsers):
Widget:Facebook Like Box
Widget:Feed
Widget:Google Calendar

The following carelessly missed some escaping:
Widget:Facebook Like Box

There were also some flash embedding video providers I won't bother
listing. They are iffy because if there's an open url redirector on the
domains they are delivered from, they could be tricked to deliver
arbitrary flash based malware.

This was just a small portion at the start of the list.

> I would not be opposed to an extension that makes high-level validation
>> and construction of simple widgets as extension code easier. Or making
>> it
>> easier to get into Gerrit so people can submit extension code and we can
>> properly review it.
>>
>
> I do think this is a great idea.
> A "widget framework" extension that ease the development of widgets
> (sub)extensions.
> That would both provide the security and the ease of use.
> The only remaining problem being that a full release would be necessary
> to
> roll out widgets.
> I was actually planning to work on that before the end of the year as a
> way
> to replace the widget extension.
> (the extension is useful, but not perfect)
>
>
>> But there is absolutely no way that the fundamentals the Widgets
>> extension
>> are based on will provide the proper environment to create secure
>> widgets.
>>
>
> Maybe the widgets extension is not secure, but can we nevertheless
> imagine
> a way to write widgets code in pages?
> Lua will certainly be able to handle the logic that smarty does now.
> We're just missing a way (for sysops) to override the parser escaping of
> <script>, <iframe>, <img>...
>
>> --
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>>
>
> To me, there is no doubt that (wiki) websites must nowadays be able to
> interact with and embed the other services their users love.
> The logic necessary to render such external services is very basic and
> easy.
> I do believe that the easiest it is to contribute, the more contribution
> you get.
> (Just look at the great amount of resources there is on
> mwwidgets.orgcompared to
> mw.org).
>
> Saving Extension:Widgets,
> or building a better extension based on the same in-page code concept,
> is worth a try.

Widgets' abundance comes from how trivial it is to Copy & Paste without
any knowledge of programming and security -- something which unfortunately
will never create something secure --. As well as how widgets are nicely
organized into a wiki rather than scattered about.
It is quite possible we could do pretty well without the code in-page
concept.

Things we'll need:
- An extension:
-- that makes high-level validation easy. (eg: Making sure a youtube video
id is in the right format)
-- with a way to eliminate much of the unnecessary boilerplate code in a
widget extension.
-- makes writing html output with secure high-level nested code structures
easy (rather than encouraging concatenation).
- Opening up Gerrit so people can quickly get in and submit their
extensions.
- An organized area that makes it easy to find extension based widgets.
Rather than scattering them through the other extensions.
- A wishlist page for widgets people want.

Most widgets don't really exist since no-one with the right skills knows
they are wanted.

Tbh if I were in my ideal working under a MediaWiki Foundation I don't
think I'd mind making one of my 20% time side projects, building simple
widget extensions that people want.

> --
> Clément Dietschy
> *Seizam* Sàrl.
> 24, rue de Bâle
> 68300 Saint-Louis (France)
> tél. +33 6 87 75 99 27
> www.seizam.com


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


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


katkov.juriy at gmail

Sep 4, 2012, 4:16 AM

Post #5 of 20 (1348 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

Maybe the widgets on the website should have security verification
badges? On the pages of secured widgets the badge would say that it's
safe to use them. As far as I know the Widgets extension designed
specially to create safe alternative to 'plain-old insertion of raw
html and javascript to wikipages'.
-----
Yury Katkov



On Tue, Sep 4, 2012 at 2:28 PM, Daniel Friesen
<daniel [at] nadir-seen-fire> wrote:
> On Tue, 04 Sep 2012 02:25:56 -0700, Clment Dietschy <clement [at] seizam>
> wrote:
>
>>>
>>> On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
>>> <sergey.chernyshev [at] gmail> wrote:
>>>
>>> > Hi everybody,
>>> >
>>> > A few years back I saw a need in easy widget creation and too many
>>> > extensions that just did that, but were not so well maintained and had
>>> > a
>>> > bunch of XSS holes in them and so on, that's when I came up with idea
>>> > of
>>> > Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets
>>
>>
>>
>> A very useful extension, enabling quick integration of external services.
>> Thanks for creating it.
>>
>>> Since individual widgets were just wiki pages, I created a standalone
>>> > wiki
>>> > where everybody can post their widgets (in special "Widget" namespace)
>>> > which will be available to everyone after basic security review (it
>>> > integrates with Flagged Revisions if it's installed):
>>> > http://www.mediawikiwidgets.org/
>>
>>
>>
>> A very useful website, but sadly dying slowly, as you said. I hope we'll
>> find a solution to save it.
>>
>>> Best,
>>> >
>>> > Sergey
>>>
>>> I don't really like this idea. I'd prefer it that the Widgets extension
>>> doesn't get any more popular than it already is.
>>>
>>> Frankly I wish I could stick an {{XSS alert}} template on that page and
>>> be
>>> done with it. But I haven't because the extension is only an enabler
>>> making it trivially easy to add an XSS hole into your wiki.
>>>
>>
>> Yes, the use of the smarty language within pages, IF misused, can be
>> dangerous.
>
>
> The larger danger is the people not misusing it. It's way to easy to write
> something the wrong way and open yourself up to attack.
>
>
>> The premise of the extension is flawed. If someone cannot be trusted to
>>>
>>> securely write a widget in PHP there is no way that they can be trusted
>>> to
>>> properly escape raw concatenated html.
>>>
>>
>> Yes, someone writing a widget through the wiki with this extension must be
>> trusted.
>> BUT not as trusted as someone writing a regular php extension
>> (There is no backend vulnerability)
>> AND, it's easier and faster to do it through the wiki.
>>
>>
>>> It basically takes extension code; Something we can put into standard
>>> repositories. Provide full pre-commit security review. Notify users of
>>> security holes. And in the future incorporate systems to tell you when
>>> there's a new version (likely with a security fix) you should upgrade to;
>>> And puts it into raw concatenated html wiki pages -- lacking in extensive
>>> escaping and high-level abstraction -- managed by users who do not
>>> necessarily have any programming skills much less a proper understanding
>>> of security. Somewhere developers naturally pay no attention to.
>>> Somewhere
>>> with no alerts about security holes, etc... And suggests that users just
>>> C&P the Widget (potentially with an open XSS vector) into their wiki and
>>> never look back to see if a critical hole has been fixed.
>>>
>>
>> True, there are more secure and synchronized ways to go.
>>
>> A number of widgets inside that site have critical XSS vectors inside of
>>>
>>> them. Every time I go back there and look at random ones it doesn't take
>>> long to find a hole.
>>
>>
>>
>> I use widgets a lot and never found such holes (but I mainly use very
>> popular ones).
>> Can you please give an example? I'm afraid there could be flaws I did not
>> see...
>
>
> Let's see... Going from A-Z in groups. Just doing some of the widgets at the
> start of the list.
>
> The following have full on script execution vulnerabilities based on tricks
> that can bypass the escaping used:
> Widget:AddThis
> Widget:DISQUS
> Widget:Feed
> Widget:Google Books
> Widget:Google Maps
> Widget:Google Street View
>
> The following have CSS based injection vulnerabilities (this is full on
> script injection in some browsers):
> Widget:Facebook Like Box
> Widget:Feed
> Widget:Google Calendar
>
> The following carelessly missed some escaping:
> Widget:Facebook Like Box
>
> There were also some flash embedding video providers I won't bother listing.
> They are iffy because if there's an open url redirector on the domains they
> are delivered from, they could be tricked to deliver arbitrary flash based
> malware.
>
> This was just a small portion at the start of the list.
>
>
>> I would not be opposed to an extension that makes high-level validation
>>>
>>> and construction of simple widgets as extension code easier. Or making it
>>> easier to get into Gerrit so people can submit extension code and we can
>>> properly review it.
>>>
>>
>> I do think this is a great idea.
>> A "widget framework" extension that ease the development of widgets
>> (sub)extensions.
>> That would both provide the security and the ease of use.
>> The only remaining problem being that a full release would be necessary to
>> roll out widgets.
>> I was actually planning to work on that before the end of the year as a
>> way
>> to replace the widget extension.
>> (the extension is useful, but not perfect)
>>
>>
>>> But there is absolutely no way that the fundamentals the Widgets
>>> extension
>>> are based on will provide the proper environment to create secure
>>> widgets.
>>>
>>
>> Maybe the widgets extension is not secure, but can we nevertheless imagine
>> a way to write widgets code in pages?
>> Lua will certainly be able to handle the logic that smarty does now.
>> We're just missing a way (for sysops) to override the parser escaping of
>> <script>, <iframe>, <img>...
>>
>>> --
>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>>>
>>
>> To me, there is no doubt that (wiki) websites must nowadays be able to
>> interact with and embed the other services their users love.
>> The logic necessary to render such external services is very basic and
>> easy.
>> I do believe that the easiest it is to contribute, the more contribution
>> you get.
>> (Just look at the great amount of resources there is on
>> mwwidgets.orgcompared to
>> mw.org).
>>
>> Saving Extension:Widgets,
>> or building a better extension based on the same in-page code concept,
>> is worth a try.
>
>
> Widgets' abundance comes from how trivial it is to Copy & Paste without any
> knowledge of programming and security -- something which unfortunately will
> never create something secure --. As well as how widgets are nicely
> organized into a wiki rather than scattered about.
> It is quite possible we could do pretty well without the code in-page
> concept.
>
> Things we'll need:
> - An extension:
> -- that makes high-level validation easy. (eg: Making sure a youtube video
> id is in the right format)
> -- with a way to eliminate much of the unnecessary boilerplate code in a
> widget extension.
> -- makes writing html output with secure high-level nested code structures
> easy (rather than encouraging concatenation).
> - Opening up Gerrit so people can quickly get in and submit their
> extensions.
> - An organized area that makes it easy to find extension based widgets.
> Rather than scattering them through the other extensions.
> - A wishlist page for widgets people want.
>
> Most widgets don't really exist since no-one with the right skills knows
> they are wanted.
>
> Tbh if I were in my ideal working under a MediaWiki Foundation I don't think
> I'd mind making one of my 20% time side projects, building simple widget
> extensions that people want.
>
>
>> --
>> Clment Dietschy
>> *Seizam* Srl.
>> 24, rue de Ble
>> 68300 Saint-Louis (France)
>> tl. +33 6 87 75 99 27
>> www.seizam.com
>
>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Sep 4, 2012, 5:02 AM

Post #6 of 20 (1349 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On 4 September 2012 12:16, Yury Katkov <katkov.juriy [at] gmail> wrote:

> Maybe the widgets on the website should have security verification
> badges? On the pages of secured widgets the badge would say that it's
> safe to use them. As far as I know the Widgets extension designed
> specially to create safe alternative to 'plain-old insertion of raw
> html and javascript to wikipages'.


The essential problem is that people can't get stuff through the
gatekeepers, so they come up with a workaround. Noting that the
workaround is insecure and saying "just don't do that" doesn't solve
the original need and won't help security. It's not clear to me what
will, but the gatekeeping is an obvious start.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Sep 4, 2012, 5:06 AM

Post #7 of 20 (1346 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, Sep 4, 2012 at 8:02 AM, David Gerard <dgerard [at] gmail> wrote:
> The essential problem is that people can't get stuff through the
> gatekeepers, so they come up with a workaround. Noting that the
> workaround is insecure and saying "just don't do that" doesn't solve
> the original need and won't help security. It's not clear to me what
> will, but the gatekeeping is an obvious start.
>

The problem with creating a new system that has no gatekeepers
is that it encourages people who have no business writing code to
end up doing so.

Lowering bars, making it easy to jump into the shallow end, giving
people feedback so they can improve--these are all good things we
can and should do.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Sep 4, 2012, 5:11 AM

Post #8 of 20 (1346 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On 4 September 2012 13:06, Chad <innocentkiller [at] gmail> wrote:
> On Tue, Sep 4, 2012 at 8:02 AM, David Gerard <dgerard [at] gmail> wrote:

>> The essential problem is that people can't get stuff through the
>> gatekeepers, so they come up with a workaround. Noting that the
>> workaround is insecure and saying "just don't do that" doesn't solve
>> the original need and won't help security. It's not clear to me what
>> will, but the gatekeeping is an obvious start.

> The problem with creating a new system that has no gatekeepers
> is that it encourages people who have no business writing code to
> end up doing so.


Yeah, I didn't say the results were *good*. Just that saying "don't do
that" won't stop it at all. The urge will be there as long as there
are gatekeepers, but the harm does need to be minimised.


> Lowering bars, making it easy to jump into the shallow end, giving
> people feedback so they can improve--these are all good things we
> can and should do.


This has long been said, of course.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeroendedauw at gmail

Sep 4, 2012, 5:11 AM

Post #9 of 20 (1351 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

Hey,

The essential problem is that people can't get stuff through the
> gatekeepers, so they come up with a workaround. Noting that the
> workaround is insecure and saying "just don't do that" doesn't solve
> the original need and won't help security. It's not clear to me what
> will, but the gatekeeping is an obvious start.
>

I don't think this extension really affects this. It is the same as having
widgets implemented as extensions in that:

* They can only be enabled by administrative people
* They can be obtained from verified sources or from non-trusted ones

Widgets are inferior in that:

* An attacker compromising an admin account can put in arbitrary JS code

Widgets are superior in that:

* They cannot create PHP vulnerabilities
* Changes can be kept track of on-wiki
* The source is clearly visible to wiki users, increasing the scrutiny of
the code
* They are easier to deploy for most people
* They encourage more collaboration compared to the tons of low qualify and
unmaintained single widget extensions

It seems to me that this extension does not lose on security compared to
regular extensions at all, and that it offers quite a few benefits for the
kind of functionality it is intended to be used for.

The problem with creating a new system that has no gatekeepers
> is that it encourages people who have no business writing code to
> end up doing so.
>

This system has as much gatekeeping as regular extensions do. I think
several people are making assumptions here without having had a decent look
at the extension.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


gregory.varnum at gmail

Sep 4, 2012, 6:26 AM

Post #10 of 20 (1348 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

I use and like this extension. I know many others do as well. This debate over its value to some and security is interesting (well - not really) but aside from the point of this thread.

Should the widgets be housed on MW.org rather than an outside site? Given their wide usage and the preference towards all things MW being on MW.org, I think they absolutely should and fully support that idea.

Don't like the extension? Don't use it. For those of us that do, this move would be very helpful. Arguing about the merits of the extension vs the value of moving its components seems irrelevant. It's widely used enough and arguing about it is unlikely to change that. Unless we're suddenly worried about storage space on MW.org this seems like it should be more about how than why.

I would propose subpages to the main extension page.

-Greg aka varnent

____________
Sent from my iPhone. Apologies for any typos. A more detailed response may be sent later.

On Sep 4, 2012, at 8:11 AM, Jeroen De Dauw <jeroendedauw [at] gmail> wrote:

> Hey,
>
> The essential problem is that people can't get stuff through the
>> gatekeepers, so they come up with a workaround. Noting that the
>> workaround is insecure and saying "just don't do that" doesn't solve
>> the original need and won't help security. It's not clear to me what
>> will, but the gatekeeping is an obvious start.
>
> I don't think this extension really affects this. It is the same as having
> widgets implemented as extensions in that:
>
> * They can only be enabled by administrative people
> * They can be obtained from verified sources or from non-trusted ones
>
> Widgets are inferior in that:
>
> * An attacker compromising an admin account can put in arbitrary JS code
>
> Widgets are superior in that:
>
> * They cannot create PHP vulnerabilities
> * Changes can be kept track of on-wiki
> * The source is clearly visible to wiki users, increasing the scrutiny of
> the code
> * They are easier to deploy for most people
> * They encourage more collaboration compared to the tons of low qualify and
> unmaintained single widget extensions
>
> It seems to me that this extension does not lose on security compared to
> regular extensions at all, and that it offers quite a few benefits for the
> kind of functionality it is intended to be used for.
>
> The problem with creating a new system that has no gatekeepers
>> is that it encourages people who have no business writing code to
>> end up doing so.
>
> This system has as much gatekeeping as regular extensions do. I think
> several people are making assumptions here without having had a decent look
> at the extension.
>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


compwhizii at gmail

Sep 4, 2012, 10:39 AM

Post #11 of 20 (1347 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, Sep 4, 2012 at 9:26 AM, Mr. Gregory Varnum
<gregory.varnum [at] gmail> wrote:
> I use and like this extension. I know many others do as well. This debate over its value to some and security is interesting (well - not really) but aside from the point of this thread.
>
> Should the widgets be housed on MW.org rather than an outside site? Given their wide usage and the preference towards all things MW being on MW.org, I think they absolutely should and fully support that idea.
>
> Don't like the extension? Don't use it. For those of us that do, this move would be very helpful. Arguing about the merits of the extension vs the value of moving its components seems irrelevant. It's widely used enough and arguing about it is unlikely to change that. Unless we're suddenly worried about storage space on MW.org this seems like it should be more about how than why.
>
> I would propose subpages to the main extension page.
>
> -Greg aka varnent
>
> ____________
> Sent from my iPhone. Apologies for any typos. A more detailed response may be sent later.
>
> On Sep 4, 2012, at 8:11 AM, Jeroen De Dauw <jeroendedauw [at] gmail> wrote:
>
>> Hey,
>>
>> The essential problem is that people can't get stuff through the
>>> gatekeepers, so they come up with a workaround. Noting that the
>>> workaround is insecure and saying "just don't do that" doesn't solve
>>> the original need and won't help security. It's not clear to me what
>>> will, but the gatekeeping is an obvious start.
>>
>> I don't think this extension really affects this. It is the same as having
>> widgets implemented as extensions in that:
>>
>> * They can only be enabled by administrative people
>> * They can be obtained from verified sources or from non-trusted ones
>>
>> Widgets are inferior in that:
>>
>> * An attacker compromising an admin account can put in arbitrary JS code
>>
>> Widgets are superior in that:
>>
>> * They cannot create PHP vulnerabilities
>> * Changes can be kept track of on-wiki
>> * The source is clearly visible to wiki users, increasing the scrutiny of
>> the code
>> * They are easier to deploy for most people
>> * They encourage more collaboration compared to the tons of low qualify and
>> unmaintained single widget extensions
>>
>> It seems to me that this extension does not lose on security compared to
>> regular extensions at all, and that it offers quite a few benefits for the
>> kind of functionality it is intended to be used for.
>>
>> The problem with creating a new system that has no gatekeepers
>>> is that it encourages people who have no business writing code to
>>> end up doing so.
>>
>> This system has as much gatekeeping as regular extensions do. I think
>> several people are making assumptions here without having had a decent look
>> at the extension.
>>
>> Cheers
>>
>> --
>> Jeroen De Dauw
>> http://www.bn2vs.com
>> Don't panic. Don't be evil.
>> --
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Does MediaWikiWiki really need any more shitty/insecure addons that no
one is going to maintain? I think we have enough already.

Pick out the best of the bunch and nuke the rest.

--
John

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


madman.enwiki at gmail

Sep 4, 2012, 11:06 AM

Post #12 of 20 (1347 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, Sep 4, 2012 at 1:39 PM, John Du Hart <compwhizii [at] gmail> wrote:
> Does MediaWikiWiki really need any more shitty/insecure addons that no
> one is going to maintain? I think we have enough already.

Does MediaWiki's development community really need any more people
discouraging volunteers by calling their good-faith contributions
shitty? I think we have enough already.

Maybe we should stick to constructive criticism.

Thanks,
-Madman

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel at nadir-seen-fire

Sep 4, 2012, 1:25 PM

Post #13 of 20 (1347 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, 04 Sep 2012 05:11:33 -0700, Jeroen De Dauw
<jeroendedauw [at] gmail> wrote:

> Hey,
>
> The essential problem is that people can't get stuff through the
>> gatekeepers, so they come up with a workaround. Noting that the
>> workaround is insecure and saying "just don't do that" doesn't solve
>> the original need and won't help security. It's not clear to me what
>> will, but the gatekeeping is an obvious start.
>>
>
> I don't think this extension really affects this. It is the same as
> having
> widgets implemented as extensions in that:
>
> * They can only be enabled by administrative people
> * They can be obtained from verified sources or from non-trusted ones
>
> Widgets are inferior in that:
>
> * An attacker compromising an admin account can put in arbitrary JS code
I forgot to mention it but here's another:
* The XSS vectors in some widgets cannot be fixed without using php.

Also:
* Concatenation of raw html leads to the creation of some really messy
Widget implementations that are hard to review.

>
> Widgets are superior in that:
>
> * They cannot create PHP vulnerabilities
Sure... assuming there are no vulnerabilities in Smarty that we don't know
about.
But you only create PHP vulnerabilities when you use something related to
eval, require with user input, save data to the filesystem, or are a
malicious person.
They're easy to weed out in simple Widget extensions that don't need to do
any of this.

> * Changes can be kept track of on-wiki
> * The source is clearly visible to wiki users, increasing the scrutiny of
> the code
Visibility of extensions in public repositories is fine. Clearly the
in-page nature of these widgets has not helped theit scrutiny at all.

> * They are easier to deploy for most people
> * They encourage more collaboration compared to the tons of low qualify
> and
> unmaintained single widget extensions
I do not believe that it is impossible for us to get good collaboration on
small widget extensions.
We need to make these cleaner to build. Let people jump into their
development more easily. Improve the ability to find them. And make a
place for users to request new ones.

>
> It seems to me that this extension does not lose on security compared to
> regular extensions at all,
Sorry but the Widgets extension has no high-level declaration of output
like we have in Html:: any relies entirely on the author knowing how to
escape everything perfectly to avoid security holes.
This is a major loss in security.
There is a very good reason besides working on multiple engines that we
work with databases using high-level abstraction rather than by
concatenating SQL.
High-level abstraction makes it easier to avoid holes, makes security
implicit and cleaner than insecurity. And makes it possible to write
cleanly nested code even when the output is a huge one-line mess.

> and that it offers quite a few benefits for the
> kind of functionality it is intended to be used for.
>
> The problem with creating a new system that has no gatekeepers
>> is that it encourages people who have no business writing code to
>> end up doing so.
>>
>
> This system has as much gatekeeping as regular extensions do. I think
> several people are making assumptions here without having had a decent
> look
> at the extension.
This is clearly not the case. Because there are XSS vectors all over these
widgets.
Developers who understand security do not monitor code strewn about in
piles of wiki pages.
They in no way have the same level of gatekeeping as extensions.

>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --

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


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


compwhizii at gmail

Sep 4, 2012, 2:13 PM

Post #14 of 20 (1349 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, Sep 4, 2012 at 2:06 PM, [[w:en:User:Madman]]
<madman.enwiki [at] gmail> wrote:
> On Tue, Sep 4, 2012 at 1:39 PM, John Du Hart <compwhizii [at] gmail> wrote:
>> Does MediaWikiWiki really need any more shitty/insecure addons that no
>> one is going to maintain? I think we have enough already.
>
> Does MediaWiki's development community really need any more people
> discouraging volunteers by calling their good-faith contributions
> shitty? I think we have enough already.
>
> Maybe we should stick to constructive criticism.
>
> Thanks,
> -Madman
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hey if you want to make mediawiki.org a dumping ground for anything
mediawiki related, have fun with that.

--
John

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeroendedauw at gmail

Sep 4, 2012, 2:14 PM

Post #15 of 20 (1345 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

Hey,

This is clearly not the case. Because there are XSS vectors all over these
> widgets.
> Developers who understand security do not monitor code strewn about in
> piles of wiki pages.
> They in no way have the same level of gatekeeping as extensions.
>

So instead of writing a widget publicly visible, the random third party
admin who barley knows the basics of PHP goes write something that quite
possibly is not published anywhere and can have gaping security holes not
known to them and remaining so. You also mention stuff such as
Html::element. Guess what - they might not know about it. I have looked at
A LOT of extensions, and I can assure you that you have a rather rosy view
on the subject.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rlane32 at gmail

Sep 4, 2012, 2:19 PM

Post #16 of 20 (1358 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

> Hey if you want to make mediawiki.org a dumping ground for anything
> mediawiki related, have fun with that.
>

Well, the parent thread had a point. Let's discuss what's possible
rather than just downing the current work. How can we make widgets a
viable extension? Is it possible? If not, can we salvage any of the
work? Maybe the widgets could be split into maintainable extensions?

For instance, there isn't a single usable extension for embedding
videos in MediaWiki. Is the implementation in widgets secure? Could we
break this into an actually maintained extension? I'm sure there's
other widgets that would be useful as well.

- Ryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


gregory.varnum at gmail

Sep 4, 2012, 2:22 PM

Post #17 of 20 (1348 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

I think that's a valuable and valid discussion.

I would also argue that adding the widgets as subpages to the widget extension isn't cluttering up the wiki much - it at all. I fail to see how that would have such a drastic impact on our use of the wiki.

-Greg

____________
Sent from my iPhone. Apologies for any typos. A more detailed response may be sent later.

On Sep 4, 2012, at 5:19 PM, Ryan Lane <rlane32 [at] gmail> wrote:

>> Hey if you want to make mediawiki.org a dumping ground for anything
>> mediawiki related, have fun with that.
>>
>
> Well, the parent thread had a point. Let's discuss what's possible
> rather than just downing the current work. How can we make widgets a
> viable extension? Is it possible? If not, can we salvage any of the
> work? Maybe the widgets could be split into maintainable extensions?
>
> For instance, there isn't a single usable extension for embedding
> videos in MediaWiki. Is the implementation in widgets secure? Could we
> break this into an actually maintained extension? I'm sure there's
> other widgets that would be useful as well.
>
> - Ryan
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel at nadir-seen-fire

Sep 4, 2012, 3:06 PM

Post #18 of 20 (1348 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

On Tue, 04 Sep 2012 14:14:34 -0700, Jeroen De Dauw
<jeroendedauw [at] gmail> wrote:

> Hey,
>
> This is clearly not the case. Because there are XSS vectors all over
> these
>> widgets.
>> Developers who understand security do not monitor code strewn about in
>> piles of wiki pages.
>> They in no way have the same level of gatekeeping as extensions.
>>
>
> So instead of writing a widget publicly visible, the random third party
> admin who barley knows the basics of PHP goes write something that quite
> possibly is not published anywhere and can have gaping security holes not
> known to them and remaining so.
Random third party admins running wikis so small they hack together custom
code don't have people who understand security reviewing anything for
vulnerabilities. Even if it's public it's going to stay vulnerable.

The only way these sites will ever have something secure is if we have a
nice widget request area where third party admins can get someone to write
a simple widget extension for some service they want to use.

> You also mention stuff such as
> Html::element. Guess what - they might not know about it. I have looked
> at
> A LOT of extensions, and I can assure you that you have a rather rosy
> view
> on the subject.
We just have bad documentation on the subject.
A proper PHP based Widget extension would provide some apis even nicer
than our current Html. Easy to use validation. Boilerplate cleanup. And
would naturally come with good documentation that encourages people to use
the high-level style of code.
Well, not just encourages... I'd say it wouldn't even mention the fact you
can concatenate strings of html.

>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --


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


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


sergey.chernyshev at gmail

Sep 4, 2012, 9:44 PM

Post #19 of 20 (1344 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

Folks,

If current implementation can be made more secure, I'm well for it -
ideally more secure then the alternative native PHP extensions
infrastructure MW has right now.

Unfortunately, this was born because writing extensions for widgets is
hard, writing them in secure way is even harder, splitting the code into
two layers maintained on different levels seemed better, especially for
small independent wikis who have hard time managing extensions.

If anyone is interested in rewriting it using more secure framework or
maybe fixing all the widgets (providing better validators or alike), you're
very welcome to do so.

There were other ideas like context-based auto-escaping, better review
process, rewrite using new version of Smarty, installation from centralized
repo and so on, but someone else sill have to continue that.

Anyway, we can kill the work of many years, that's easy, more over, it'll
die alone without active commitment anyway, I hope good open source
community like MW team can find out a way to utilize this work.

If there is any help needed, I'm eager to help with the move as I did
before by maintaining Widgets, OpenID extension and contributing to
Semantic MediaWiki/Forms/Bundle and so on - it's just time for me to step
away from MW development.

Best,

Sergey


On Tue, Sep 4, 2012 at 6:06 PM, Daniel Friesen
<daniel [at] nadir-seen-fire>wrote:

> On Tue, 04 Sep 2012 14:14:34 -0700, Jeroen De Dauw <jeroendedauw [at] gmail>
> wrote:
>
> Hey,
>>
>> This is clearly not the case. Because there are XSS vectors all over these
>>
>>> widgets.
>>> Developers who understand security do not monitor code strewn about in
>>> piles of wiki pages.
>>> They in no way have the same level of gatekeeping as extensions.
>>>
>>>
>> So instead of writing a widget publicly visible, the random third party
>> admin who barley knows the basics of PHP goes write something that quite
>> possibly is not published anywhere and can have gaping security holes not
>> known to them and remaining so.
>>
> Random third party admins running wikis so small they hack together custom
> code don't have people who understand security reviewing anything for
> vulnerabilities. Even if it's public it's going to stay vulnerable.
>
> The only way these sites will ever have something secure is if we have a
> nice widget request area where third party admins can get someone to write
> a simple widget extension for some service they want to use.
>
>
> You also mention stuff such as
>> Html::element. Guess what - they might not know about it. I have looked at
>> A LOT of extensions, and I can assure you that you have a rather rosy view
>> on the subject.
>>
> We just have bad documentation on the subject.
> A proper PHP based Widget extension would provide some apis even nicer
> than our current Html. Easy to use validation. Boilerplate cleanup. And
> would naturally come with good documentation that encourages people to use
> the high-level style of code.
> Well, not just encourages... I'd say it wouldn't even mention the fact you
> can concatenate strings of html.
>
>
>
>> Cheers
>>
>> --
>> Jeroen De Dauw
>> http://www.bn2vs.com
>> Don't panic. Don't be evil.
>> --
>>
>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
>
> ______________________________**_________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


questpc at rambler

Sep 5, 2012, 3:53 AM

Post #20 of 20 (1350 views)
Permalink
Re: Moving MediaWikiWidgets.org to Wikimedia [In reply to]

> 4 Сентябрь 2012 г. 21:40:20 пользователь John Du Hart (compwhizii [at] gmail) написал:
>
>
> Does MediaWikiWiki really need any more shitty/insecure addons that no
> one is going to maintain? I think we have enough already.
>
> Pick out the best of the bunch and nuke the rest.
>
It is not easy (at least here in Russia) to earn anything via programming MediaWiki extensions. I made some extensions, two for local university and 3 or 4 as freelancer job. They were paid just once. And you have to write them in fixed time, that's why many parts of code aren't cleaned / polished up. While new versions of MediaWiki introduce new functionality, sometimes incompatibility with old extensions. It seems that extension-writing must be full-time paid job, however nobody of employers here wants that. They want minimal, single-time expenses. I guess that's why there are many abandoned and low-quality extensions. Struggling with low income problems is not nice thing, especially for the people who have families.
Dmitriy

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.