Hey,
I just had Certificate Patrol in Firefox let me know that the SSL cert for
Wikimedia.org was changed? Does anyone know anything about that? Are multiple
certificates in use?
Old cert:
- Builtin Object Token:Equifax Secure CA
- *.wikimedia.org
SHA1: BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
Issued: 2010-08-03 11:43:56 (1346 days ago)
Expires: 2015-08-22 18:23:10 (499 days ahead)
New cert:
- GeoTrust Global CA
- RapidSSL CA
- *.wikimedia.org
SHA1: A4:5B:84:1B:A8:00:DC:1B:2E:11:71:E6:31:C6:5D:0E:AF:50:10:95
Issued: 2014-04-06 18:31:08 (4 days ago)
Expires: 2015-08-24 19:09:19 (501 days ahead)
I rejected the certificate for the moment, but saved a copy of both if anyone
wants to take a look.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Greetings!
I am happy to let you know that we have just launched Media Viewer 0.2 on our first pilot site, MediaWiki.org, where it is now enabled by default for all users (previously, it was only available as a Beta Feature).
Media Viewer aims to improve the multimedia viewing experience on Wikipedia and Wikimedia sites, to display images in larger size and with less clutter — as well as invite more people to use our images.
We invite you to try out this new tool today, which you can do on this test page:
https://www.mediawiki.org/wiki/Lightbox_demo
Please let us know what you think on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
You can learn more about this new tool here:
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
After this first pilot, we plan to enable Media Viewer by default for these next pilot sites:
• April 17 - Confirmed: Catalan, Hungarian, Korean, English Wikivoyage
• April 24 - Proposed: Czech, Estonian, Finnish, Hebrew, Polish, Romanian, Thai, Slovak, Vietnamese
Based on these first pilot results, we plan wider releases on larger wikis in the following weeks, with a goal to deploy to all wikis next month. Our release schedule will be based on new findings at each stage of deployment. If this product performs well and meets user needs, we may accelerate the deployment pace -- or we may slow it down for some sites, as needed.
More details are available in this release plan:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
To discuss this release and review the final product together, we invite you to join our next IRC chat, on Wed. Apr. 9 at 18:00 UTC. We also invite you to try out the tool on your own wikis, where it is available for early testing as a Beta Feature in your user preferences, as described above.
Please let us know if you have any questions, suggestions or comments about this release. And many thanks to all the community members who helped create this feature with us in recent months!
We look forward to bringing a richer multimedia experience to your community very soon.
Regards as ever,
Fabrice
on behalf of the Multimedia Team
https://www.mediawiki.org/wiki/Multimedia
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09
This Wednesday, I'd like to get some quick "is this RfC still
valid/what's the next step?" checks on a few of our older RfCs. The list
I currently suggest we look at:
UserMailer refactor
Nonlinear versioning
AuthStack
Abstract table definitions
Support for user-specific page lists in core
If you can't make this meeting, and you care about one of these RfCs, it
would be great if you could comment on its talkpage before the meeting.
Thanks!
We'll talk at Wednesday at 2200 UTC
http://www.wolframalpha.com/input/?i=2200+utc+in+pt in #wikimedia-office
on Freenode.
midnight in Berlin (sorry)
6pm in Montreal
3pm in California
8am in Sydney, Australia
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Dear list members,
I am pleased to announce the release of WP-MIRROR 0.7.
0) SUMMARY
The main design objective was this: RENDERING.
A page rendered by the mirror is now very similar to the same page
rendered by the WMF server. Indeed, not only do pages look almost the
same, they now *behave* almost the same (e.g. editting, searching,
user account creation, beta features).
Most of this improvement was accomplished by packaging `mediawiki
1.23' and dozens of its extensions including: EasyTimeline, Math,
Mobile Frontend, Score, Scribunto, Timed Media Handler, Titlekey,
Universal Language Selector, Visual Editor, and Wikidata.
A mirror of the `wikidata wiki' is now built `out-of-the-box', and
provides data to the other wikis (e.g. for populating infoboxes).
Mirrors of `simplewiki' and `simplewiktionary' are also build
`out-of-the-box' as before.
1) PACKAGING
Dependencies: Four new DEB packages were prepared as dependencies for
WP-MIRROR 0.7:
o mediawiki-mwxml2sql_0.0.2-2_amd64.deb: contains an upgrade of
`mwxml2sql' suitable for processing XML dumps for mediawiki 1.23.
o wp-mirror-mediawiki_1.23-1_all.deb: contains git branch wmf/1.23wmf14.
o wp-mirror-mediawiki-extensions_1.23-1_all.deb: contains 47
extensions from git branch wmf/1.23wmf14 (except for the `Wikidata'
extension which is from git branch mw1.23-wmf11)
o wp-mirror-mediawiki-extensions-math-texvc_1.23-1_amd64.deb: contains
programs needed to render MathJax.
Testing: The DEB package for WP-MIRROR 0.7 works `out-of-the-box'
with no user configuration for the following distributions:
o Debian GNU/Linux 7.4 (wheezy) with backports. This has been tested
on both a host machine, and on a virtual machine.
2) INSTALLATION
WP-MIRROR 0.7 is now available in the form of a Debian package repository.
3) USE
Virtual Hosts: Browsing of mirrored wikis is done via virtual hosts
with names like <http://simple.wikipedia.site/>,
<http://simple.wiktionary.site/>, and <http://www.wikidata.site/>.
Simply take the URL that WMF offers, and replace `.org' with `.site'.
3) FURTHER INFO
Project Home Page: <http://www.nongnu.org/wp-mirror/> has been
updated. Please browse there if you are interested in trying
WP-MIRROR.
Documentation has been updated. There is a new section on virtual
machines; and there is a new section on the `mediawiki' extensions
that were packaged for this release.
Feedback is welcome.
4) ACKNOWLEDGEMENTS
I would like to thank several people for providing valuable assistance.
o Jason Cooper - for recommendations on DEB packaging, repository
design, and hosting; and for getting me interested in virtual
machines, which are now part of my tool chain (this is how I test that
WP-MIRROR 0.7 works `out-of-the-box' on a clean install of Debian
7.4).
o Kevin Day - for providing IPv6 support at <ftpmirror.your.org>,
which is highly appreciated by those of us on IPv6 only networks.
o Frederico Leva (Nemo) - for advice that helped track down a bug with
XML dump importation.
o Gnosygnu - for many pointers on Wikidata, Scribunto, database schema
changes, and XOWA thumb dumps.
o Guy Castagnoli - for performing a code review of WP-MIRROR 0.6,
which led to numerous improvements in WP-MIRROR 0.7; and for spending
an evening with me discussing a wide range of topics including: news
of other offline projects, showing me how pages are rendered on his
mobile devices, and starting a list of feature requests for a future
WP-MIRROR 0.8 (requests for features including parsoid, importation of
daily dumps, generation of thumb dumps and ZIM files).
Sincerely Yours,
Dr. Kent L. Miller
Hi,
As part of recent work on Media Viewer we've introduced new data attributes
to thumbnails (affecting only wikis where the extension is installed):
https://gerrit.wikimedia.org/r/#/c/121613/3/MultimediaViewerHooks.php,unifi…
These attributes currently help us display a placeholder image 500ms sooner
on average and will soon allow us to display the actual image 500ms sooner
as well, which is a huge performance gain in the context of Media Viewer.
However at the moment articles can only benefit from it if they have been
re-saved since this code was deployed.
Is there a way - for the wikis hosted by the foundation where Media Viewer
is deployed - to gradually re-save or somehow invalidate all articles?
Doing this with a code change that would invalidate all articles at once is
probably undesirable, since this would create a huge spike in web server
and Varnish load. So, I was wondering if this can be done with a job or a
bot, and if there is precedence or existing tools to perform such a task.
Hi I am Natesh Relhan . I am a B-Tech student in JIIT Noida . I plan to
propose a idea which implements a gallery part in Wikimedia Commons Android
app and have further categorizations based on contents .
https://www.mediawiki.org/wiki/User:NateshR/Gsoc_Proposal_2014
The MultiUpload extension has been unmaintained for a while. I believe
its author has moved on to another job. I've written a completely
independent piece of extension code (as a byproduct of work I did for
the WorkingWiki extension) that provides a multiple-upload interface.
After consulting with Petrb, who is listed as the current maintainer of
MultiUpload on mediawiki.org, I'm thinking of checking in my
multiple-upload code as a new version of MultiUpload, completely
replacing the current implementation.
I'm posting here in case anyone objects or cares to raise concerns.
Here's a bare-bones demo video: https://www.youtube.com/watch?v=4d90Tt5EGAc
And here's my extension, in a temporary location:
https://github.com/worden-lee/MultiUpload
Lee Worden
Hello,
A reminder that the Language Engineering IRC office hour will be
happening later today at 1700UTC/1000PDT on #wikimedia-office. Please
see below for the original announcement, local time and other details.
Thanks
Runa
Monthly IRC Office Hour:
==================
# Date: April 9, 2014
# Time: 1700 UTC/1000PDT (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140409T1700)
# IRC channel: #wikimedia-office
# Agenda:
1. Translation file format changes
2. Other project updates
3. Q & A (Questions can be sent to me ahead of the event)
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Apr 4, 2014 at 9:09 PM
Subject: Language Engineering IRC Office Hour on April 09, 2014
(Wednesday) at 1700 UTC
To: MediaWiki internationalisation
<mediawiki-i18n(a)lists.wikimedia.org>, Wikimedia developers
<wikitech-l(a)lists.wikimedia.org>, Wikimedia Mailing List
<wikimedia-l(a)lists.wikimedia.org>,
wikitech-ambassadors(a)lists.wikimedia.org
[x-posted]
Hello,
The Language Engineering team will be hosting the next monthly IRC
office hour on Wednesday, April 9 2014 at 1700 UTC at
#wikimedia-office.
We will be discussing about our recent work and provide updates
related to changes in the translation file format (PHP to JSON) for
MediaWiki core and extensions. As always, we will be taking questions
during the session.
Please see below for event details and local time. See you at the office hour.
Thanks
Runa
Monthly IRC Office Hour:
==================
# Date: April 9, 2014
# Time: 1700 UTC/1000PDT (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140409T1700)
# IRC channel: #wikimedia-office
# Agenda:
1. Translation file format changes
2. Other project updates
3. Q & A (Questions can be sent to me ahead of the event)
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
FYI to this audience as well:
We're reseting all user session tokens today due to heartbleed.
What I didn't state below is that we have already replaced our SSL certs
as well as upgraded to the fixed version of openssl.
----- Forwarded message from Greg Grossmeier <greg(a)wikimedia.org> -----
> Date: Tue, 8 Apr 2014 13:54:26 -0700
> From: Greg Grossmeier <greg(a)wikimedia.org>
> To: Wikitech Ambassadors <wikitech-ambassadors(a)lists.wikimedia.org>
> Subject: Security precaution - Resetting all user sessions today
>
> Yesterday a widespread issue in OpenSSL was disclosed that would allow
> attackers to gain access to privileged information on any site running a
> vulnerable version of that software. Unfortunately, all Wikimedia
> Foundation hosted wikis are potentially affected.
>
> We have no evidence of any actual compromise to our systems or our users
> information, but as a precautionary measure we are resetting all user
> session tokens. In other words, we will be forcing all logged in users
> to re-login (ie: we are logging everyone out).
>
> All logged in users send a secret session token with each request to the
> site and if a nefarious person were able to intercept that token they
> could impersonate other users. Resetting the tokens for all users will
> have the benefit of making all users reconnect to our servers using the
> updated and fixed version of the OpenSSL software, thus removing this
> potential attack.
>
> As an extra precaution, we recommend all users change their passwords as
> well.
>
>
> Again, there has been no evidence that Wikimedia Foundation users were
> targeted by this attack, but we want all of our users to be as safe as
> possible.
>
>
> Thank you for your understanding and patience,
>
> Greg Grossmeier
>
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |