Le 21.6.2008 5:17, « aaron(a)svn.wikimedia.org » <aaron(a)svn.wikimedia.org> a
écrit :
> Revision: 36519
> Author: aaron
> Date: 2008-06-21 03:17:35 +0000 (Sat, 21 Jun 2008)
>
> Log Message:
> -----------
> * Revert r36478; I don't see the point in this cryptic code
> * Restore r36273 as explain on mailing list
>
> Modified Paths:
> --------------
> trunk/phase3/includes/Article.php
> trunk/phase3/includes/ProtectionForm.php
> trunk/phase3/includes/Title.php
The problem is that if you want to introduce a new protection level (e.g.
userrights to allow only bureaucrats to edit that page) and that all groups
that have this right also have the "protect" right (wich is correct if you
give bureaucrats the protect right), then you should be able to use cascade
protection for this level. Note that the protection level should be an
right, and not a group (execpt for "sysop" kept for b/c) and it's why
there's an loop on $wgGroupPermission (see also Simetrical's message on
brion's revert of r36273).
This code only allows cascade with the protect level, for a normal install,
it works as expected, but for custom levels (as I mentionned before), it
doesn't work as only can have cascade on one level so I really don't see the
point to have "protect" hardcoded in that check.
--ialex
On Fri, Jun 20, 2008 at 2:46 PM, <demon(a)svn.wikimedia.org> wrote:
> No need to count(*) in SiteStats::admins
> ...
> - self::$admins = $dbr->selectField( 'user_groups', 'COUNT(*)', array( 'ug_group' => 'sysop' ), __METHOD__ );
> + self::$admins = $dbr->selectField( 'user_groups', 'COUNT(ug_group)', array( 'ug_group' => 'sysop' ), __METHOD__ );
What is this intended to do? ug_group is NOT NULL; COUNT(ug_group)
will always be identical to COUNT(*).
On Thu, Jun 19, 2008 at 6:07 AM, <raymond(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> * Per Nikerabbits suggestion: Move vertical-align into CSS
> * Move text-align into CSS too.
>
> Modified Paths:
> --------------
> trunk/phase3/includes/DefaultSettings.php
> trunk/phase3/includes/specials/Preferences.php
> trunk/phase3/skins/modern/main.css
> trunk/phase3/skins/modern/rtl.css
> trunk/phase3/skins/monobook/main.css
> trunk/phase3/skins/monobook/rtl.css
> trunk/phase3/skins/simple/main.css
> trunk/phase3/skins/simple/rtl.css
Surely this should just change shared.css. This appears to be a
regression for non-Monobook-based skins (e.g., Cologne Blue), and is
also overly verbose (changes unnecessarily many files).
On Thu, Jun 19, 2008 at 2:00 PM, <brion(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Revert r36273:
> The change was described only as "Fix confused code", but it changed from something
> that appears to make sense (check for a permission key for that restriction group)
> to something that doesn't (hardcoded check for two particular names).
>
> If the change has an effect, and there's a reason for it, please describe it
> in a bit more detail.
The point that was brought up is that except for in the special case
of 'sysop', protection levels are rights, not groups. It makes no
sense to check $wgGroupPermissions[$restrictions]; if it exists, it's
only by accident, because a group happens to have the same name as the
permission being checked for.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
raymond(a)svn.wikimedia.org wrote:
> Revision: 36357
> Add 'svn-revision' and 'svn-date' to extensionCredits where missing for extensions used on WMF servers
[snip]
> + 'svn-date' => '$LastChangedDate$',
> + 'svn-revision' => '$LastChangedRevision$',
I should warn that these basically always give wrong results.
They only get updated when the *particular file* changes; in extensions
consisting of multiple files (eg, every extension that follows our
current coding standards), this means that the "version number" only
gets updated when the configuration-and-hook-definition file is updated,
not when the actual code changes.
I'd recommend removing them, as they are misleading and counterproductive.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhaue4ACgkQwRnhpk1wk44O/gCg1lxH5Z//tGCIkaslpL2m+Np7
2VEAoLQEg64KpPPPBRY6sB2JGEzsgNPU
=P0AM
-----END PGP SIGNATURE-----
On 19/06/2008, mfarag(a)svn.wikimedia.org <mfarag(a)svn.wikimedia.org> wrote:
> Revision: 36456
> Author: mfarag
> Date: 2008-06-19 14:46:50 +0000 (Thu, 19 Jun 2008)
>
> Log Message:
> -----------
> Add support for Higri (Islamic) calendar
>
> Patch by AhmadSherif
Is it Higri or Hijri? Currently both are used inconsistently.
--
Niklas Laxström
[apologies if this is an old suggestion]
We're seeing a spammer who is persistently vandalizing multiple
pages with a certain URL. The URL is on the blacklist, so the
spammer is now just spelling it out, without any hotlink markup.
See [[Wikipedia:Administrators' noticeboard/Incidents#Ref desk spam]],
See [[Wikipedia:Administrators' noticeboard/Incidents#Anontalk spammer]],
and [[Wikipedia:Village pump (technical)#Making various types of
spam/vandalism that little bit more difficult]].
I realize there's an infinite-regress cat-and-mouse game here,
of which a "plaintext" link blacklist implementation is just one
more step, but it seems it might be an appropriate next step.
(I have no idea what it would require implementationally, however.)
Dear members of the Wikimedia project,
we kindly ask for your participation in our survey on security assurance in
free/open source software.
Security assurances are confidence building activities through structured
design processes, documentation, and testing.
By participating in our survey you contribute to ongoing research with the
aim to make free/open source software more secure.
It will not take more than 10 minutes of your valuable time for our 21
questions.
Our survey is online for the next two weeks until July 1 at:
http://survey.mi.fu-berlin.de/public/survey.php?name=fosssecurity
Please find the results of the survey on the project page during July:
https://www.inf.fu-berlin.de/w/SE/FOSSSecuritySurvey
For further information about Open Source research at the Research Group
Software Engineering at
Freie Universitaet Berlin, please visit:
https://www.inf.fu-berlin.de/w/SE/FOSSHome
Thank you in anticipation,
Sascha Rasmussen, Alexander Kunze, and Andre Haralevich
In case you participate in more than one FOSS project, please fill out the
questionnaire for the one where security is most important, or fill out one
questionnaire per project.
Thank you!