Mz writes:
> I received this message twice. Ten-four!
My apologies to you and the list. I re-sent it because I saw it on mediawiki-l but not on wikitech-l.
> Can you please create a 2014 timeline of expected releases? Or at least
> the first half of 2014?
Yes. I'll do that this week, maybe even tonight.
Mark.
Subject: Monthly point releases
Based on the issues raised during a meeting we had at the Architecture Summit a couple of weeks ago, those of us involved in MediaWiki release management have decided to introduce a monthly point-release cycle. On the last Thursday of every month we'll collect fixes that have been made and release them for download.
We plan to continue to use the "Known Issues" subpage[1] to drive the issues that are incorporated into the release. This means that if you have an issue that you think should be addressed before the next major release, you can add it to the "Known Issues" page. We'll review it and, if we agree that it is an appropriate issue for a point release, then we'll try to get it resolved.
Of course, this is a community-driven effort, so issues that have working code attached are more likely to be resolved in a point release than requests without code. If you cannot provide patches, that doesn't mean that your issue won't be fixed. Instead, you can help us find someone to fix it and further help by testing any fixes provided.
We hope that this will mean a more usable MediaWiki.
Thanks,
Mark.
[1] https://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues
Hi lists,
If you haven't patched with the last security release, or know of a wiki
that hasn't patched yet, please do so immediately. An exploit was released
on the full disclosure mailing list over the weekend[1] that targets the
vulnerability in the PdfHandler extension.
If you're not able to patch for some reason, you may be able to work around
the issue:
* If you have never allowed .djvu files to be uploaded, but you do allow
pdf files, you can simply disable the PdfHandler extension (typically by
remove the include in your LocalSettings.php).
* If you have any .djvu files saved on your wiki, then there is no
workaround-- you need to apply the security patch to MediaWiki core.
If anyone is running an unsupported branch of MediaWiki (1.20 was recently
EOL'ed), and needs help creating a patch for their instance, I'm happy to
try and work with you to get the vulnerability closed. Contact me off list,
or on irc.
[1] - http://seclists.org/fulldisclosure/2014/Feb/6
On Mon, Jan 13, 2014 at 9:10 AM, Chris Steipp <csteipp(a)wikimedia.org> wrote:
>> To satisfy Applebaum's request, there needs to be a mechanism whereby
>> someone can edit even if *all of their communications with Wikipedia,
>> including the initial contact* are coming over Tor or equivalent.
>> Blinded, costly-to-create handles (minted by Wikipedia itself) are one
>> possible way to achieve that; if there are concrete reasons why that
>> will not work for Wikipedia, the people designing these schemes would
>> like to know about them.
> This should be possible, according to https://meta.wikimedia.org/wiki/NOP,
> which Nemo also posted. The user sends an email to the stewards (using tor
> to access email service of their choice). Account is created, and user can
> edit Wikimedia wikis. Or is there still a step that is missing?
I tested the existing process by creating a new riseup.net email
account via Tor, then requesting account creation and a global
exemption via stewards(a)wikimedia.org. My account creation request was
granted, but for exemption purposes, I was requested to go through the
process for any specific wiki I want to edit. In fact, the account was
created on Meta, but not exempted there.
The reason I gave is as follows:
"My reason for editing through Tor is that I would like to write about
sensitive issues (e.g. government surveillance practices) and prefer not
to be identified when doing so. I have some prior editing experience, but
would rather not disclose further information about it to avoid any
correlation of identities."
This seems like a valid reason for a global exemption to me, so I'm
not sure the current global policy is sufficient.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
The title pretty much say what I need
1) Retrieve the page - page must not be changed starts NOW
2) Do something what requires user input, possibly may last few minutes
3) Save the page ONLY if it wasn't changed, if it was, go back to step 1
this all needs to be done using API, I thought that edit token would
help me here, so that I would fetch the token at step 1 and edit using
it at step 3, hoping it expire if someone edit the page meanwhile. But
this doesn't seem to work according to documentation, because edit
token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably
something more reliable than just storing the timestamp and comparing
it (in theory someone could edit the page even in short time when
timestamp is compared). I need some super-safe lock that prevent all
possible race conditions here.
Hi, I am thinking of implementing a
#CATQUERY <query>
magic keyword for the category pages.
When this keyword is present, the category page would execute a query
against the search backend instead of normal category behavior and show
result as if those pages were actually marked with this category.
For example, this would allow Greek Philosophers category page to be
quickly redefined as
a cross-section of greeks & philosophers categories:
#CATQUERY incategory:Greek incategory:Philosopher
Obviously the community will be able to define much more elaborate queries,
including the ordering (will be supported by the new search backend)