Hello,
I have changed the Jenkins permission system a few minutes ago.
Previously, any authenticated user could change the whole configuration.
The new scheme is:
- anonymous : can read
- authenticated with a labs account : can read, manually trigger a
Gerrit change.
- 'wmf' LDAP group : can do anything
There are very few people doing configuration changes, so that new
scheme should not cause any harm.
cheers,
--
Antoine "hashar" Musso
Hi all. When working on a wiki extension I came across this thread
(http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/051437.html)
regarding the purpose/history of setFunctionTagHook() and where/when to use
it.
Daniel Friesen wrote:
"setFunctionTagHook was added so that you could expand variables inside
tags. Then setHook() got added $frame and the need for such hook type
disappeared. I'd like to kill it, although it has been there for some
time (if any list reader uses it, please stand up)."
I started using the hook in a Firebase extension
(http://www.mediawiki.org/w/index.php?title=Extension:Firebase)
in order to replace <firebaseraw> tags with responses to HTTP requests
/before most other wiki text is parsed/.
It works great for me because I can insert data into chunks of code like a
google street view widget:
{{#widget:Google Street View
|lat=<firebaseraw url="http://gamma.firebase.com/SomeAccountName/lat" />
|lng=<firebaseraw url="http://gamma.firebase.com/SomeAccountName/lon" />
|yaw=370.64659986187695
|pitch=-20
|zoom=0
}}
I'm new to extension writing, though, so maybe there are other, better ways
to accomplish this?
If not, consider this a vote to leave in setFunctionTagHook()!
--Benny
Hi all,
I am trying to find a (any) html file in gerrit (trying to find out whether it is displayed as HTML in a browser, but that is not the issue here…). When I enter “html” in the search box, it apparently searches commit messages for html (?). When I try the search syntax as described here [1], I get an invalid query error. Is there any documentation on what search operators I can use or how the search works in general? Any hints are greatly appreciated :)
Cheers,
Markus
[1] http://gerrit.googlecode.com/svn/documentation/2.1.4/user-search.html
It's been a long time coming (for the nth time..), but we're scheduling a
deployment of HTML5 across the Wikimedia cluster [1]. This is set for Monday
17th September at 18:00-20:00 UTC [2].
The intention is to set $wgHtml5 [3] to true everywhere. It's been running
on MediaWiki.org and our 2 test wikis for quite a while, and other sites
like translatewiki.net with no issues.
The intention is to leave it enabled unless it causes major problems. If
you're running an application that screen scrapes, shame on you; you've had
enough notice to get it fixed! ;)
Now is the time to fix up your scripts and programs (where necessary), tell
your friends!
Sam
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
[2] http://wikitech.wikimedia.org/view/Software_deployments#Week_of_Sept_17
[3] https://www.mediawiki.org/wiki/Manual:$wgHtml5
Forwarding to Wikitech-l on request :)
Tom
---------- Forwarded message ----------
From: Jon Davies <jon.davies(a)wikimedia.org.uk>
Date: 6 September 2012 10:48
Subject: Request for a developer.
To: Wikimedia UK lists <wikimediauk-l(a)lists.wikimedia.org>
Having failed to find someone full time as a developer we are licking our
wounds and thinking of a plan 'c'.
Plan 'b' ,in the meantime, is to offer the support work for the fundraiser
as a tender to an individual or individuals who would like to take on the
work.
Our deadlines are super tight so expressions of interest by 5pm on the 14th
of September.
Please pass this around to anyone you know, mailing lists etc. I have
tried to post to wikitech-l but am not subscribed. Can someone make sure
this happens?
http://uk.wikimedia.org/wiki/Request_for_Developer_tender
Many thanks
Jon
--
*Jon Davies - Chief Executive Wikimedia UK*. Mobile (0044) 7803 505 169
tweet @jonatreesdavies
Wikimedia U.K. is a Company Limited by Guarantee registered in England and
Wales, Registered No. 6741827. Registered Charity No.1144513
Registered Office 4th Floor, Development House, 56-64 Leonard Street,
London EC2A 4LT. United Kingdom.
Telephone (0044) 207 065 0990.
Wikimedia UK is the UK chapter of the Wikimedia Movement. It is an
independent non-profit organization with no legal control over Wikipedia
nor responsibility for its contents.
Visit http://www.wikimedia.org.uk/ and @wikimediauk
Greetings All,
We have updated the app on Google
Play<https://play.google.com/store/apps/details?id=org.wikipedia.wlm>with
some important fixes and enhancements.
Here is a separate download link:
*http://dumps.wikimedia.org/android/WLM-v1.2.2.apk*<http://dumps.wikimedia.org/android/WLM-v1.2.2.apk>
Changes in this version:
* Dynamically load campaign data - picks up campaign config changes without
requiring a new version of the app
* Camera and location features marked as optional to increase device
compatibility
* Localisation updates
* Increased accuracy when communicating with GPS satellites
* Disables 'Cancel upload' button when it is too late to cancel
* Bigger touch areas for checkboxes
* Moves {{Uploaded with WLM Mobile}} template to the source field on file
page
* Translated country name on monument page
* Fixed admin level display
* Strip bold/italic apostrophe markup from wikitext fields
* 'Back' after upload no longer returns you to upload progress
* Consistent photo upload comments
* Cache monuments in certain situations to reduce API calls
* Monument pin clustering disabled when zoomed in
* Lossless image compression
The app is now also available of the FOSS market, F-droid, at:
*http://f-droid.org/repository/browse/?fdid=org.wikipedia.wlm*<http://f-droid.org/repository/browse/?fdid=org.wikipedia.wlm>
We are working on more fixes and enhancements, including a handy way to
upload more photos on Commons. This will make any mobile upload a
convenient placeholder for desktop uploads.
Please let us know if you have any issues by email or on the feedback
page<http://www.mediawiki.org/wiki/Wiki_Loves_Monuments_mobile_application/Feedb…>
.
We have a new page for help with monument data issues:
https://www.mediawiki.org/wiki/Wiki_Loves_Monuments_mobile_application/Data…
Phil
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810
>
> On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
> <sergey.chernyshev(a)gmail.com> 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.
--
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
Please note that this is a breaking change for bots!
It is decided that the module wbsetitem will change from the present
"short form" in the json structure to a "long form". Exactly how the
long form will be is still a bit open, but it will be closer to the
json output format. The changes also makes it possible to use a
key-less format as the language and site id will be available inside
the long form.
The following short form will be WRONG in the future
{
"labels":{
"de":"Foo",
"en":"Bar"
}
}
This long form will be RIGHT in the future
{
"labels":{
"de":{"value":"Foo","language":"de"},
"en":{"value":"Bar","language":"en"}
}
}
And also this will be RIGHT
{
"labels":[
{"value":"Foo","language":"de"},
{"value":"Bar","language":"en"}
]
}
New modules may use a long form if they support json input, but that
for the future.
In some cases it seems necessary to add flags for what to do with
individual fields, but perhaps we can avoid it. (Typically for
adding/removing aliases, but it could also be necessary for other
fields.)
There are also a new "clear" URL argument that will clear the content
of an item and make it possible to rebuild it from scratch. Default
behavior is NOT to clear the content, but to incrementally build on
the existing item.
Also note that use of [no]usekeys in the URL is not supported anymore.
See also
* http://www.mediawiki.org/wiki/Extension:Wikibase/API#New_long_format
/jeblad
Version with helpful links:
https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews
1) Write small commits.
It's easier for other people to review small changes that only change
one thing. We'd rather see five small commits than one big one.
2) Respond to test failures and feedback.
Check your Gerrit settings and make sure you're getting email
notifications. If your code fails automated tests, or you got some
review already, respond to it in a comment or resubmission. Or hit the
Abandon button to remove your commit from the review queue while you
revise it.
(To see why automated tests fail, click on the link in the "failed"
comment in Gerrit, hover over the failed test's red dot, wait for the
popup to show, and then click "console output.")
3) Don't mix rebases with changes.
When rebasing, only rebase. That makes it easier to use the "Old Version
History" dropdown, which greatly quickens reviews. If non-rebase changes
are made inside a rebase changeset, you have to read through a lot more
code to find it and it's non-obvious.
4) Add reviewers.
I try to help with this. If I notice an unreviewed changeset lingering,
then I add a review request or two. (These are requests -- there's no
way to assign a review to someone in Gerrit.) But it's faster if you do
it right after committing. Some tricks:
* Click the name of the repository ("Gerrit project"), e.g.
operations/debs/squid , and remove "status:open" from the search box to
find other changesets in that repository. The people who write and
review those changesets would be good candidates to add as reviewers.
* Search through other commit summaries and changesets. Example:
Matmarex and Foxtrott are interested in reviewing frontend changes, so I
search for "message:css" to find changesets that mention CSS in their
commit summaries to add them to. You can use this and regexes to find
changes that touch the same components you're touching, to find likely
reviewers. Learn more at
https://gerrit.wikimedia.org/r/Documentation/user-search.html .
5) Review more.
Many eyes make bugs shallow. Read the code review guide and help out
with comments, "+1", and "-1". Those are nonbinding, won't cause merges
or rejections, and have no formal effect on the code review. But you'll
learn, gain reputation, and get people to return the favor by reviewing
you in the future. "How to review code in Gerrit" has the step-by-step
explanation. Example Gerrit search for MediaWiki commits that have not
had +1, +2, -1, or -2 reviews yet:
https://gerrit.wikimedia.org/r/#/q/-CodeReview%252B1+-CodeReview%252B2+-Cod…
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation