Hi everyone,
I am an engineering student from Bits Pilani (India) currently in my 5th and final year.I seek to apply for GSOC this year under Mediawiki. So from the list of ideas given on the Mediawiki gsoc page, I wish to work on building a convention extension which would help convert any wiki into a conference like website such as Wikimania.After having discussions over IRC channels regarding the features that this extension should possess , and some feedback that I got from other developers I have written a proposal for this extension. I would really appreciate any feedback in this short period of time left, as it would help me in setting the right deliverables for this project. The proposal page - http://www.mediawiki.org/wiki/User:Chughakshay16/GSOCProposal%282012%29 The other details about this extension can be found on the following pages: 1. implementation details (+UI mockups) - http://www.mediawiki.org/wiki/User:Chughakshay16/ConventionExtension 2. database details - http://www.mediawiki.org/wiki/User:Chughakshay16/databasedetails The talk pages for the above can also be used for the feedback.
Thanks, Akshay Chugh (irc - chughakshay16)
On Tue, Apr 3, 2012 at 4:46 AM, wikitech-l-request@lists.wikimedia.orgwrote:
Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Wikitech-l digest..."
Today's Topics:
- Re: Time to redirect to https by default? (Ryan Lane)
- Re: Time to redirect to https by default? (Ryan Lane)
- Re: Time to redirect to https by default? (Ryan Lane)
- Re: Time to redirect to https by default? (MZMcBride)
- Re: Committing followups: please no --amend (Chad)
- Re: Time to redirect to https by default? (Platonides)
- Re: Time to redirect to https by default? (Ryan Lane)
- rsync on scap/sync reporting 'no space left on device' for a lot of hosts (Arthur Richards)
- Re: Time to redirect to https by default? (Antoine Musso)
Message: 1 Date: Tue, 3 Apr 2012 03:34:13 +0900 From: Ryan Lane rlane32@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: <CALKgCA0RLExmwpdJ18ATtPJ_b=h7JBc7AJ=Pj+2zgUYvnRPJ4w@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 2, 2012 at 12:33 PM, Tim Starling tstarling@wikimedia.org wrote:
On 02/04/12 06:14, Ryan Lane wrote:
TL;DR: we have no plans for anonymous HTTPS by default, but will eventually default to HTTPS for logged-in users.
- It would require an ssl terminator on every frontend cache. The ssl
terminators eat memory, which is also what the frontend caches do.
Once we enable it by default for logged-in users, we will care a lot more if someone tries to take it down with a DoS attack. Unless the redirection can be disabled without actually logging in, a DoS attack on the HTTPS frontend would prevent any authenticated activity.
It suggests a need for a robust, overprovisioned service, with tools and procedures in place for identifying and blocking or throttling malicious traffic.
Indeed. We're already pretty over provisioned. We have 4 servers per datacenter, each of which is very bored. All they are doing is acting as a transparent proxy, after ssl termination. We're using RC4 by default (due to BEAST), and AES is also available (the processors we are using have AES support).
Ideally we'll be using STS for logged in users. This will mean it's impossible to turn off the redirection for users that have already logged in for whatever period of time we have STS headers set. We need to consider blocking a DoS from the SSL proxies, the LVS servers, or the routers.
- Some countries may completely block HTTPS, but allow HTTP to our
sites so that they can track users. Is it better for us to provide them content, or protect their privacy? 4. It's still possible for governments to see that people are going to wikimedia sites when using HTTPS, so it's still possible to oppress people for trying to visit sites that are disallowed.
It's also possible for governments to snoop on HTTPS communications, by using a private key from a trusted CA to perform a man-in-the-middle attack. Apparently the government of Iran has done
this.
We really should publish our certificate fingerprints. An attack like this can be detected. An end-user being attacked can see if the certificate they are being handed is different from the one we advertise. We could also provide a convergence notary service (or one of the other things like convergence).
If we really want to protect the privacy of our users then we should shut down the regular website and serve our content only via a Tor hidden service ;)
I agree that it's impossible to provide total protection of a user's privacy. We could provide a number of services that would help users, though. That said, I don't feel this should be on the top of our priority list.
- Ryan
Message: 2 Date: Tue, 3 Apr 2012 03:58:41 +0900 From: Ryan Lane rlane32@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: <CALKgCA1ZXK8TBedG4cgdLeg-LsW7aN=ujf9O2V0QKL33DUYDVA@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 2, 2012 at 4:20 PM, Petr Bena benapetr@gmail.com wrote:
That's not what I wanted to say, I wanted to say "https may cause troubles with caching", In fact some caching servers have problems with https since the header is encrypted as well, so they usually just forward the encrypted traffic to server. I don't say it's impossible to cache this, but it's very complicated
Using SSL by default means all transparent proxies inbetween aren't hit at all, since they'd be a MITM. I don't necessarily see this as a bad thing, as transparent proxies often break things.
Browsers cache things differently from HTTPS sites, but otherwise everything should work as normal. The SSL termination proxies transparently proxy to our frontend caches after termination. Links are sent as protocol-relative so that we don't split our cache, as well.
- Ryan
Message: 3 Date: Tue, 3 Apr 2012 04:00:32 +0900 From: Ryan Lane rlane32@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: <CALKgCA18yzdDpiqS1RAViaz8O7nw68K2Bz0qZaCp1i0g1TxTNg@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 2, 2012 at 6:34 PM, Tei oscar.vives@gmail.com wrote:
Perhaps have a black list of countries that are know to break the privacy of communications, then make https default for logued users in these countries.
This may help because:
?- It only affect a subgroup of users (the ones from these countries) ?- It only affect a subgroup of that subgroup, ?the logued users (not
all)
?- It create a blacklist of "bad countries" where citizens are under surveillance by the governement
This perhaps is not feasible, if theres not easy way to detect the country based on the ip.
I'd definitely not support doing something like this. This would incredibly complicate things.
- Ryan
Message: 4 Date: Mon, 02 Apr 2012 16:26:57 -0400 From: MZMcBride z@mzmcbride.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: CB9F83D1.18E9B%z@mzmcbride.com Content-Type: text/plain; charset="ISO-8859-1"
Ryan Lane wrote:
On Mon, Apr 2, 2012 at 6:34 PM, Tei oscar.vives@gmail.com wrote:
Perhaps have a black list of countries that are know to break the privacy of communications, then make https default for logued users in these countries.
This may help because:
?- It only affect a subgroup of users (the ones from these countries) ?- It only affect a subgroup of that subgroup, ?the logued users (not
all)
?- It create a blacklist of "bad countries" where citizens are under surveillance by the governement
This perhaps is not feasible, if theres not easy way to detect the country based on the ip.
I'd definitely not support doing something like this. This would incredibly complicate things.
Someone came into #wikimedia-tech a few days ago and asked about something similar to this. The idea was to use site-wide JavaScript to auto-redirect users to https on one of the Chinese Wikipedias. I believe this was in combination with geolocation functionality, but I'm not sure.
Do you have any thoughts on individual wikis doing this, assuming there's local community consensus?
MZMcBride
Message: 5 Date: Mon, 2 Apr 2012 17:05:03 -0400 From: Chad innocentkiller@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Committing followups: please no --amend Message-ID: <CADn73rPYs_H5tR0fQ0bvwAkjrJTnhA3Tk52FmLj1RbsekMp38A@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 27, 2012 at 6:06 AM, Tim Starling tstarling@wikimedia.org wrote:
On 27/03/12 19:49, Roan Kattouw wrote:
On Mon, Mar 26, 2012 at 9:50 PM, Tim Starling tstarling@wikimedia.org
wrote:
For commits with lots of files, Gerrit's diff interface is too broken to be useful. It does not provide a compact overview of the change which is essential for effective review.
Luckily, there are alternatives, specifically local git clients and gitweb. However, these don't work when git's change model is broken by the use of git commit --amend.
They do; it just wasn't obvious to you how to do it, but that doesn't mean it can't be done.
$ git fetch https://gerrit.wikimedia.org/r/p/analytics/udp-filters refs/changes/22/3222/3 && git branch foo FETCH_HEAD $ git fetch https://gerrit.wikimedia.org/r/p/analytics/udp-filters refs/changes/22/3222/4 && git branch bar FETCH_HEAD $ git diff foo..bar
The two 'git fetch' commands (or at least the part before the &&) can be taken from the change page in Gerrit.
It doesn't work, I'm afraid. Because of the implicit rebase on push, usually subsequent changesets have a different parent. So when you diff between the two branches, you get all of the intervening commits which were merged to the master.
Examples from today:
https://gerrit.wikimedia.org/r/#change,3367 Patchsets 1 and 2 have different parents.
https://gerrit.wikimedia.org/r/#change,3363 Patchsets 1, 2 and 3 have different parents.
It's possible to get a diff between them, and I did, but it's tedious. I figure we should pick a workflow that doesn't waste the reviewer's time quite so much.
The problem here is the implicit rebase. As long as the review backlog isn't long and/or people aren't submitting conflicting changes, rebasing amended changes against master creates more harm than good.
For amending commits, you should use `git review -R` so you don't rebase the change (again) against master (see for example [0], difference between patch 2 and 3). I've updated the docs[1], but they are, briefly:
git review -d 123 (make changes) git commit -a --amend git review -R
If you're not using git-review and have been using the alias, your amended patchsets have not been creating this problem.
-Chad
[0] https://gerrit.wikimedia.org/r/#change,4020 [1] https://www.mediawiki.org/wiki/Git/Workflow#Amend_your_change
Message: 6 Date: Mon, 02 Apr 2012 23:31:28 +0200 From: Platonides Platonides@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: jld5hm$suh$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
On 02/04/12 20:34, Ryan Lane wrote:
It's also possible for governments to snoop on HTTPS communications, by using a private key from a trusted CA to perform a man-in-the-middle attack. Apparently the government of Iran has done
this.
We really should publish our certificate fingerprints. An attack like this can be detected. An end-user being attacked can see if the certificate they are being handed is different from the one we advertise. We could also provide a convergence notary service (or one of the other things like convergence).
Indeed. Detecting a potential MITM is useless if you can't determine if it's real or not. For instance the switch from RapidSSL to DigiCert certificate was quite suspicious.
I don't know how to best publicise it, though. I suppose we would list them somewhere like https://secure.wikimedia.org/servers.html but if nobody knows it's there...
Message: 7 Date: Tue, 3 Apr 2012 06:35:50 +0900 From: Ryan Lane rlane32@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: <CALKgCA0xW+wJu5LxzxQrJTaUfAf1ELPFjfucVeHaBF8CbaJjAw@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Indeed. Detecting a potential MITM is useless if you can't determine if it's real or not. For instance the switch from RapidSSL to DigiCert certificate was quite suspicious.
I don't know how to best publicise it, though. I suppose we would list them somewhere like https://secure.wikimedia.org/servers.html but if nobody knows it's there...
What's https://secure.wikimedia.org?
- Ryan
Message: 8 Date: Mon, 2 Apr 2012 16:19:20 -0700 From: Arthur Richards arichards@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] rsync on scap/sync reporting 'no space left on device' for a lot of hosts Message-ID: <CAG5Yvh+pr-=KLLzj2sVucWX5a8PJG1mb=sd+0wc+FK+0KZpybw@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
I just ran scap and saw the following for a lot of hosts:
srv285: rsync: write failed on "/usr/local/apache/common-local/php-1.19/cache/l10n/l10n_cache-ab.cdb": No space left on device (28)
srv285: rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7]
srv285: rsync: connection unexpectedly closed (2051 bytes received so far) [generator]
srv285: rsync error: error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7]
Also, on configchange:
mw21: rsync: write failed on "/apache/common-local/wmf-config/CommonSettings.php": No space left on device (28)
mw21: rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7]
mw21: rsync: connection unexpectedly closed (37 bytes received so far) [generator]
mw21: rsync error: error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7]
Not sure if this is a problem and/or if others are aware/working on it, but thought I'd mention it.
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687
Message: 9 Date: Tue, 03 Apr 2012 01:22:10 +0200 From: Antoine Musso hashar+wmf@free.fr To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Time to redirect to https by default? Message-ID: jldcat$bto$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
On April 2nd, 2012 at 23:35, Ryan Lane wrote:
Some old experiment. Nothing to see here :-)
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 105, Issue 10
On 03.04.2012, 11:51 akshay wrote:
Hi everyone,
Hi, please see https://meta.wikimedia.org/wiki/Mailing_lists#Using_digests
I am an engineering student from Bits Pilani (India) currently in my 5th and final year.I seek to apply for GSOC this year under Mediawiki. So from the list of ideas given on the Mediawiki gsoc page, I wish to work on building a convention extension which would help convert any wiki into a conference like website such as Wikimania.After having discussions over IRC channels regarding the features that this extension should possess , and some feedback that I got from other developers I have written a proposal for this extension. I would really appreciate any feedback in this short period of time left, as it would help me in setting the right deliverables for this project. The proposal page - http://www.mediawiki.org/wiki/User:Chughakshay16/GSOCProposal%282012%29 The other details about this extension can be found on the following pages:
- implementation details (+UI mockups) -
http://www.mediawiki.org/wiki/User:Chughakshay16/ConventionExtension 2. database details - http://www.mediawiki.org/wiki/User:Chughakshay16/databasedetails The talk pages for the above can also be used for the feedback.
Some comments on proposal details:
- user profile pages for the attendees
We already have userpages, don't we? ;)
- special badge feature for the attendees
What is it?
- payment gateway - for managing the financial transactions occurring during the conference
Seems overkillish for a summer project.
- some custom tags to design the conference wiki pages.
What is it and why not just use templates?
- poll management - for setting up polls across the conference
There are existing solutions for polls.
How are you going to write special pages and API modules before the database access layer?
Max, I have taken your points into consideration, and have made changes to my proposal.Have also narrowed down the scope as well. updated proposal : - www.mediawiki.org/wiki/User:Chughakshay16/GSOCProposal(2012)
How are you going to write special pages and API modules before the
database access layer? honest mistake :)(corrected that in my project schedule)
Thanks, Akshay Chugh (irc- chughakshay16)
Hi there Akshay,
I've talked with a few Wikimania folks - and I think there's some interest in this. My impression is our current system is a series of patch jobs done to evolve the original system to our growing needs. A complete rewrite seems fitting, from what I've seen and heard.
I'm curious if you've had a chance to speak with Wikimania folks as well - especially the ops folks doing the web forms and such. I imagine they'd have a wealth of opinions on what has worked and what wasn't worked thus far. I would also be curious what some Hackathon and other event organizers might have to say. Ideally doing a rewrite will include all the various needs (well - as many as reasonably possible..) from these folks so more more patchwork would need to be done in the foreseeable future.
Here's the IRC channel for Wikimania and other contact info: http://wikimania2012.wikimedia.org/wiki/IRC http://wikimania2012.wikimedia.org/wiki/Organizing_team
-greg aka varnent
On Apr 3, 2012, at 10:17 AM, akshay chugh chughakshay16@gmail.com wrote:
Max, I have taken your points into consideration, and have made changes to my proposal.Have also narrowed down the scope as well. updated proposal : - www.mediawiki.org/wiki/User:Chughakshay16/GSOCProposal(2012)
How are you going to write special pages and API modules before the
database access layer? honest mistake :)(corrected that in my project schedule)
Thanks, Akshay Chugh (irc- chughakshay16) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org