Reading this thread and thinking about the proposed changes, im getting
stuck, and there may be some inconsistencies. The problems identified seem
to be
1. Core development is made much harder because of an abundance in local
differences in wikis caused by local js and css.
2. Local wikis security may be compromised by lack of formalised structured
code review of local js and css. (by staff/core developers?)
The former seems to be generally acknowledged, and a large problem, the
latter more or less debated, and a smaller problem (is that correct)
Fixing 1 pretty much seems unfixable apart from completely banning local js
altogether, which is something we don't want to do. Most of the solutions
proposed as a compromise focus on fixing 2 by use of code review tools and
standards, while still using 1 as a reason, though it actually does nothing
to fix it.
Is 2 still big enough of a problem to be fixed? If so, what does it need
most? A more structured approach? More staffers reviewing gadgets? The use
of the same tooling core uses?
To me it seems more people doing review is a good thing, but are there
enough resources for that? "There should be more review" more or less
implies that that should be done by people who have +2 in core right now.
I'm not sure if that is indeed the way to read former posts, but if it is,
that is probably a bad idea. Apart from the additional workload that would
cause - in this scenario I imagine loads and loads of patches waiting for
review - it again moves the responsibility for maintaining a local wiki to
a centralized body, which is bad for the local community.
Alternatively, if we want other people to do the code review (e.g. local
admins), shouldn't we be asking them what tools they need, if any, to
effectively review and deploy patches, rather than centrally decide it for
them? If we do ask them, I sincerely doubt their answer will be git and
gerrit.
As far as centralized gadgets go, lets not worry too much about those until
the infrastructure for them actually exists.
On Dec 12, 2013 8:58 AM, "Chad" <innocentkiller(a)gmail.com> wrote:
+1 to everything MZM said.
Except the XSS in user/site/gadget JS vs core/extension XSS. Intuition
tells me the former is much more common. We just think about
core/extension
XSS because it gets a security release and tons of
attention.
-Chad
On Dec 11, 2013 8:01 PM, "MZMcBride"
<z(a)mzmcbride.com> wrote:
> Bartosz Dziewoński wrote:
> >I really liked what Jon said at the beginning, and what has apparently
> >been lost in the discussions already – "Keep gadgets for experiment,
but
> >ensure global gadgets are held to a higher
standard of quality and made
> >more visible to a wider audience.". Proper global gadgets still don't
> >exist, but when they finally happen, experienced coders who do this
for a
> >living should take them under their wings (to
clean up existing code,
to
> >check new contributions – but a
"post-merge" code-review might still be
> >more appropriate); but local gadgets should stay the safe haven of
> >innovation they are now.
>
> Yep. We should obviously find ways to improve performance and reduce
> unnecessary code. Global (Wikimedia-wide) gadgets would be a good
approach
> to take. Converting successful JavaScript gadgets
into PHP MediaWiki
> extensions would be another good approach to take. There are others.
>
> The idea being proposed in bug 58236, as it was framed, was a
non-starter.
> It simply riled people up and caused them to
become defensive. (Its
> sibling bugs didn't help.) However, if we re-frame the issue, I think
many
> people would agree that if there's a desire
to enable a gadget for _all_
> users, whatever functionality that is being provided by that gadget
> probably ought to be integrated into a MediaWiki extension.
>
> Brian Wolff wrote:
> >Submitting patches is not the problem. Getting them reviewed in a
> >timely fashion is a problem. Having power taken out of local wikis
> >hands is a problem.
>
> Yep.
>
> Brian Wolff also wrote:
> > I also think it would be unenforcable unless one plans to ban personal
> >js in all forms.
>
> Quite: if you ban site-wide JavaScript (Common.js, Monobook.js, gadgets,
> etc.), people will simply revert to using per-user JavaScript (i.e.,
> User:Foo/script.js) and importScript(), as they did for years.
>
> Tyler Romeo wrote:
> >I'll be frank. I don't really care. If power is really the issue, then
let
> >people from the wikis have +2 on their
wiki's Gerrit project.
>
> Currently you already have a +1/+2 model on the wiki. Any user can +1
> while any local administrator can +2.
>
> Tyler Romeo also wrote:
> >If the cost of increasing site-wide security and alleviating
developers'
> >pain is a few upset users who will get over
it in a month or two, then
so
> >be it.
>
> With respect, your posts exhibit hints that you have not been a
community
> member of a Wikimedia wiki, though perhaps
I'm mistaken. I find it much
> easier to agree with Bartosz and Brian than with you. It's very
important
> that wikis have sovereignty and freedom to
experiment.
>
> Daniel Friesen wrote:
> >Bartosz Dziewoński wrote:
> >>And it's not very easy to cause a major security bug when writing code
> >>that runs client-side and usually only in response to user action.
> >>Most gadgets don't, say, parse untrusted input from *other* users.
> >
> >That's not always true. There are a variety of scenarios where a Gadget
> >author may do something relatively common and innocent, and through a
> >bad practice mistake could inadvertently introduce a gaping XSS vector
> >that could be used to attack any user for whom said gadget is merely
> >enabled.
>
> While it's probably impossible to accurately measure, anecdotal evidence
> suggests that XSS vulnerabilities are far more common in MediaWiki core
> and its extensions and than in JavaScript gadgets. :-)
>
> Jon Robson wrote:
> >I'd love us to get into a situation where Gadgets continue to be a
> >platform for innovation but community and developers work hard to
mature
> >these gadgets into performant, test protected
beasts that live in a
> >single code repository. I do feel at times that we treat our users like
> >dirt in terms of their experience...
>
> Further anecdotal evidence: I hear a lot of users complain about
MediaWiki
> extensions (UniversalLanguageSelector,
ArticleFeedbackv5, FlaggedRevs)
and
> even occasionally about MediaWiki core, all of
which go through formal
> code review. I don't hear many complaints about JavaScript gadgets or
CSS.
In fact, in my
experience certain actions (such as nominating a page for
deletion) have become nearly impossible without the use of gadgets.
MZMcBride
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l