Re: [Wikitech-l] RT

[MZMcBride]

Ryan Lane wrote:
> On Tue, Oct 26, 2010 at 4:39 PM, a b  wrote:
>> After the recent dicussions open open-ness and clarity with requests by
>> serveral people what is contained within the RT after several people have
>> asked and given answers like "it's staff stuff".
>> 
>> So what is stored in it that can't be within either the staff or internal
>> wiki where it must be private or bugzilla for other matters?
> 
> RT is used by the ops team to track and plan operations work. It may
> contain procurement information, quotes, and other sensitive
> information that can not be released to the public due to contractual
> or confidentiality reasons.

Just as a clarification for readers, "RT" refers to "Request Tracker", an
open source issue tracker by Best Practical Solutions[1] used by the
Wikimedia operations team.[2] According to the server admin log it was set
up on August 10, 2010.[3] I'm not sure RT has been discussed publicly (at
least on a mailing list) before now. There is a bit more information about
it at .

While I can see the value of having a private place to put confidential
information like server price quotes, for better or worse, it seems that RT
is being used to track issues that could likely be tracked by Bugzilla. That
said, I can't see what the difference between using RT and using an internal
wiki would be.

MZMcBride

[1] http://www.bestpractical.com/rt/
[2] http://rt.wikimedia.org/
[3] http://wikitech.wikimedia.org/index.php?oldid=29466#August_10



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Parallel computing project

[James Salsman]

Aryeh Gregor writes:
>
> To clarify, the subject needs to 1) be reasonably doable in a short
> timeframe, 2) not build on top of something that's already too
> optimized

Integrating a subset of RTMP (e.g. the
http://code.google.com/p/rtmplite subset) into the chunk-based file
upload API -- http://www.mediawiki.org/wiki/API:Upload#Chunked_upload
-- would be an example of parallel I/O that we really need if we ever
hope to have reasonable microphone uploads for Wiktionary
pronunciation collection.  I know Flash sucks, but it sucks way less
for microphone upload than currently nonexistent HTML5 audio upload
support, client side Java, or any other alternative, and probably will
suck way less than any of those alternatives for years.  Soon GNU
Gnash should have microphone Speex upload on all three major
platforms, assuming the Gnash programming team doesn't starve to death
first.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New installer is here

[Rob Lanphier]

On Tue, Oct 26, 2010 at 10:00 AM, Chad  wrote:
> This has been a long development process for almost 2 years
> now, and I'd like to thank Max, Mark H., Jure, Jeroen, Roan
> and Siebrand for their invaluable help in working on this. And
> especially thanks to Tim for starting the project and providing
> feedback, as always. There is a *lot* of code in includes/installer,
> and I'd like to highlight some of the major changes that you'll
> need to know.

This is fantastic work.  Great job everyone involved!

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Firesheep

[Tisza Gergő]

Conrad Irwin  gmail.com> writes:

> There is no real massive load caused by https at runtime.  There is however
> a significant chink of developer and sysadmin time needed to implement this
> and make it work.

Secure login in itself shouldn't require reconfiguration of the SSL
architecture, though. The login form could simply redirect to a page on the
secure server, and use the image cookie method already in use for global logins.
That would take care of password stealing without requiring extensive
configuration or development efforts, and cookie stealing in itself is not that
much of an issue: only admin sessions are worth stealing, and the chances of an
attacker happening to be next to an admin on open wifi are very small. (Sure, it
would be better to provide a decent https interface and require them to use it,
because script injection is not a good thing, but apparently it won't happen
anytime soon, and we shouldn't hold back on implementing secure login because of
that.)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Firesheep

[Ashar Voultoiz]

On 26/10/10 08:45, George Herbert wrote:
> The current WMF situation is becoming "quaint" - pros use
> secure.wikimedia.org, amateurs don't realize what they're exposing.

I released a small patch today that let a user login with HTTPS. It is 
in trunk as r75585 :

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75585

The feature is optional with $wgSecureLogin (ala Aryeh, default false).

-- 
Ashar Voultoiz


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Security warning to trunk users running tests

[Platonides]

Since r61917 (3 February), running the api tests have been creating a
user called 'Useruser' which initially had a random password. r72475
(6 September) screwed up by using a hardcoded pasword.
Since it wasn't too bad for wikis allowing account creation, r74118
(1 October) made that user a sysop. Finally, r74213 (3 October) split it
into two users.

I added in r75588 a feature to block weak passwords, which will disable
them.
In r75589 I reverted to random password users and renamed them so that they
a) Are much more unlikely to conflict with any human account creation.
b) It is clear where did such sysop come from.

Sadly, we can't add them to $wgReservedUsernames without breaking the tests.

Any user having run 'make destructive' in the last two months should
update to r75589 inmediatly. They are also encouraged to desysop and
block the accounts 'Useruser' and 'Useruser1'. They are only at risk if
that install is publicly accessible, though.

Users not running MediaWiki from trunk or which haven't run the phpunit
tests are unaffected.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l