Re: [Wikitech-l] A potential land mine
On 23/08/2009, at 2:17 AM, dan nessett wrote: --- On Sat, 8/22/09, Platonides platoni...@gmail.com wrote: How's that better than MW_CONFIG_PATH environment variable? My understanding is that the administrators of certain installations cannot set environmental variables (I am taking this on faith, because that seems like a very very restricted site). What I suggested takes no work at all by installers or wiki administrators. MWInit.php (or whatever people want to name it) is part of the distribution. When you run a command line utility you have to be able to type something like php some name.php. If you can do that, you should be able to type php -d directory where MWINI.php is located some name.php. $ MW_INSTALL_PATH=/var/wiki/mediawiki php maintenance/update.php -- Andrew Garrett agarr...@wikimedia.org http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A potential land mine
--- On Sun, 8/23/09, Andrew Garrett agarr...@wikimedia.org wrote:
$ MW_INSTALL_PATH=/var/wiki/mediawiki php/maintenance/update.php
I don't understand the point you are making. If an MW administrator can set
environmental variables, then, of course, what you suggests works. However,
Brion mentions in his Tues, Aug 11, 10:09 email that not every MW installation
admin can set environmental variables and Aryeh states in his Tues, Aug. 11,
10:09am message that some MW administrators only have FTP access to the
installations they manage. So, as I understand it some administrators cannot
use the tactic you describe.
An important issue is whether these admins have access to command line
utilities at all. If not, then the use of file position dependent code in
command line utilities can be eliminated by substituting:
$IP = getenv( 'MW_INSTALL_PATH' );
if ( $IP === false ) die();
for (taken from dumpHTML.php):
$IP = getenv( 'MW_INSTALL_PATH' );
if ( $IP === false ) {
$IP = dirname(__FILE__).'/../..';
This works if only admins who can set environmental variables can execute MW
command line utilities.
If there are administrators who can execute command lines, but cannot set
environmental variables (e.g., they are confined to use a special shell), then
what I suggested in the previous email eliminates file position dependency.
That is, the command line would be:
php -d include_path=include_path in php.ini:directory to MWInit.php
utility.php
If an admin can execute php utility.php, he should be able to execute the
prior command.
Dan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A potential land mine
--- On Sun, 8/23/09, dan nessett dness...@yahoo.com wrote: In my last email, I quoted Andrew Garret: $ MW_INSTALL_PATH=/var/wiki/mediawiki php/maintenance/update.php This was incorrect. I fumbled some of the editing in my reply. What he proposed was: $ MW_INSTALL_PATH=/var/wiki/mediawiki php maintenance/update.php Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A potential land mine
On Sun, Aug 23, 2009 at 8:48 PM, dan nessettdness...@yahoo.com wrote: I don't understand the point you are making. If an MW administrator can set environmental variables, then, of course, what you suggests works. However, Brion mentions in his Tues, Aug 11, 10:09 email that not every MW installation admin can set environmental variables and Aryeh states in his Tues, Aug. 11, 10:09am message that some MW administrators only have FTP access to the installations they manage. So, as I understand it some administrators cannot use the tactic you describe. If they can run commands on the command line, then they can use environment variables. If they can't, then your suggestion doesn't help. If there are administrators who can execute command lines, but cannot set environmental variables (e.g., they are confined to use a special shell) There aren't. That would make no sense. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for August 17, 2009 - August 24, 2009 Status changes this week Bugs NEW : 130 Bugs ASSIGNED : 8 Bugs REOPENED : 21 Bugs RESOLVED : 104 Total bugs still open: 3830 Resolutions for the week: Bugs marked FIXED : 67 Bugs marked REMIND : 0 Bugs marked INVALID: 11 Bugs marked DUPLICATE : 17 Bugs marked WONTFIX: 2 Bugs marked WORKSFORME : 3 Bugs marked LATER : 4 Bugs marked MOVED : 0 Specific Product/Component Resolutions User Metrics New Bugs Per Component Site requests 12 General/Unknown 6 General/Unknown 4 Semantic MediaWiki 3 UsabilityInitiative 2 New Bugs Per Product MediaWiki 15 Wikimedia 18 MediaWiki extensions16 Wikipedia Mobile1 Top 5 Bug Resolvers brion [AT] wikimedia.org14 innocentkiller [AT] gmail.com 12 alex.emsenhuber [AT] bluewin.ch 12 agarrett [AT] wikimedia.org 7 Simetrical+wikibugs [AT] gmail.com 4 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] please make wikimedia.org mailing lists searchable
GM == Gregory Maxwell gmaxw...@gmail.com writes: GM On Sat, Aug 22, 2009 at 11:20 PM, jida...@jidanni.org wrote: All I know is I don't know of any other examples of security through obscurity on mailing lists. Wasn't Jimbo inventing a new search engine? I don't know though... can't search for the announcement. GM Download the gzipped mbox files from when you were not subscribed, for GM example http://lists.wikimedia.org/pipermail/foundation-l/2009-July.txt.gz GM Import this into the client software of your choice. Enjoy your GM new-found ability to search. Why have each user jump through such hoops, and still leave this door open to the the bad guys whoever they are. Anyway my preferred client is http://www.google.com/ so that won't help anyway. I don't see why all the years and years of technical discussion must be held at ransom just because one article where someone said one thing that he is afraid his future employer will see or something. Just remove that one article for heavens sake, and ask the user concerned to be more careful in the future. Or say: We here at Wikimedia are happy to announce that beginning of 09/09/2009 the Wikimedia mailing lists will again allow search engines to index. Any users who wish an article they wrote to be removed can contact us at any time... What if the Linux Kernel list had to be held at ransom just because one little article? How could anybody look up a technical problem that had been encountered in the past? How can one instruct good netiquette that one should first check if a problem has been solved in the past before posting a question, if there is no way to check? (Other than hoping that something got indexed anyway elsewhere due to leaks (I.e., gmane, telling us to look there while not willing to index primarily, is cheating.). How can one user's one personal problem hold all those technical references at ransom? What other organization blackholes their entire technical discussions just because one person's one time personal problem? Remove the thing that is bothering that user, and then get these lists back into Google where they belong. The usual way organizations deal with sensitive discussions is to have a separate closed personal problems list that is not indexed, instead of taking down all the other lists, North Korean style. (Mr. Peachy, I have left the formatting in this time. Thanks.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
