Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Aug 6, 2014 8:57 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything The solution to stolen credentials is to combine all credentials so that a single credential can control everything? --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
I think we should start looking at alternative authentication systems especially for high risk accounts. There are several variations on the theme of one-time passwords that I think could bd explored. Pine On Aug 6, 2014 11:05 PM, Brian Wolff bawo...@gmail.com wrote: On Aug 6, 2014 8:57 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything The solution to stolen credentials is to combine all credentials so that a single credential can control everything? --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
Meta comment: if our common goal is to increase collaboration, then we need to excel ourselves in this collaboration precisely. If we minority of tech-aware contributors are being confrontational between ourselves, then we can only expect to nurture more confrontation than collaboration among the new tech contributors we aim to engage. So please, let's enjoy this conversation and let's help each other finding better ideas to improve this problem we all want to solve. On Wed, Aug 6, 2014 at 4:01 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote: - encourage feedback by absolutely /anyone/ about the next features they'd like, Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only bugs. 99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it. Yes, I agree. Can we do better? I think the core of the problem is how to increase the participation of tech-curious contributors, and how to structure it in a way that informs, influences, and actually joins the development process effectively. How can we increase the participation in technical matters among Wikimedia editors and readers? For some thoughts on this topic, see https://commons.wikimedia.org/wiki/File:Wikimedia_technical_volunteer_outreach.jpg https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipedia_first_26213 Increasing participation by volume of participants is a goal per se. However, this participation needs to be somewhat structured in order to become efficient. For instance, having more Tech Ambassadors is good, but wouldn't it be better if we all knew which Wikimedia projects and areas of expertise are they covering? I even think that having a sense of meritocracy among tech ambassadors would be useful, just like it is useful at some point to know who is an official maintainer of a repository, who has been granted permissions to merge new code. Am I referring to the Technology Committee that Pine is proposing? I don't know. What I know is that tech meritocracy (and any meritocracy) works better when it emerges from the grassroots, and therefore I'm skeptical about any process that would start with a mandate from the Board or with a WMF goal. There are many smart, productive, and dedicated technical volunteers in our community. In relation to the problems we are describing here, they have an understanding, an experience, and a vision that most board members and WMF employees can't match. I wonder what do they think, what would they do? And I wonder how can the rest of us help them. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
Call it Bob. Bob is always a good name. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
We could name it in honor of Jimbo. ;) On Aug 7, 2014 1:18 AM, David Gerard dger...@gmail.com wrote: Call it Bob. Bob is always a good name. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
As someone with one of those high risk accounts, one time passwords would be more likely to make me drop those permissions. Any administrator has a high risk account given the opportunities that they have. Risker/Anne On 7 August 2014 07:59, Pine W wiki.p...@gmail.com wrote: I think we should start looking at alternative authentication systems especially for high risk accounts. There are several variations on the theme of one-time passwords that I think could bd explored. Pine On Aug 6, 2014 11:05 PM, Brian Wolff bawo...@gmail.com wrote: On Aug 6, 2014 8:57 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything The solution to stolen credentials is to combine all credentials so that a single credential can control everything? --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
something something Unicorn. On Aug 6, 2014, at 2:32 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: When api.php was basically the only API in MediaWiki, calling it the API worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying the API is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like the api.php API. I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
Quim, can you clarify your comments about the Technology Committee? The committee is my proposal as a community member; it is not a top-down, Board-created idea. Its membership is designed to be broadly representative of the MediaWiki user community. The Board mandate is necessary to give TechCom similar placement to AffCom, the FDC, and other community-led and Board-chartered committees that report directly to the Board. I am not sure how you see TechCom as anything but a community-based organization. Pine On Aug 7, 2014 12:33 AM, Quim Gil q...@wikimedia.org wrote: Meta comment: if our common goal is to increase collaboration, then we need to excel ourselves in this collaboration precisely. If we minority of tech-aware contributors are being confrontational between ourselves, then we can only expect to nurture more confrontation than collaboration among the new tech contributors we aim to engage. So please, let's enjoy this conversation and let's help each other finding better ideas to improve this problem we all want to solve. On Wed, Aug 6, 2014 at 4:01 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote: - encourage feedback by absolutely /anyone/ about the next features they'd like, Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only bugs. 99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it. Yes, I agree. Can we do better? I think the core of the problem is how to increase the participation of tech-curious contributors, and how to structure it in a way that informs, influences, and actually joins the development process effectively. How can we increase the participation in technical matters among Wikimedia editors and readers? For some thoughts on this topic, see https://commons.wikimedia.org/wiki/File:Wikimedia_technical_volunteer_outreach.jpg https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipedia_first_26213 Increasing participation by volume of participants is a goal per se. However, this participation needs to be somewhat structured in order to become efficient. For instance, having more Tech Ambassadors is good, but wouldn't it be better if we all knew which Wikimedia projects and areas of expertise are they covering? I even think that having a sense of meritocracy among tech ambassadors would be useful, just like it is useful at some point to know who is an official maintainer of a repository, who has been granted permissions to merge new code. Am I referring to the Technology Committee that Pine is proposing? I don't know. What I know is that tech meritocracy (and any meritocracy) works better when it emerges from the grassroots, and therefore I'm skeptical about any process that would start with a mandate from the Board or with a WMF goal. There are many smart, productive, and dedicated technical volunteers in our community. In relation to the problems we are describing here, they have an understanding, an experience, and a vision that most board members and WMF employees can't match. I wonder what do they think, what would they do? And I wonder how can the rest of us help them. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
Do you have anything specific in mind? Hard to say how feasible something is/evaluate without being more specific. Most non-password alternatives that I can think of (e.g. Having public private key pairs or something) have the problem that they can't really be integrated well enough into a web browser based environment that folks other than the most technical of users find them an acceptable burden. --bawolff On 8/7/14, Pine W wiki.p...@gmail.com wrote: I think we should start looking at alternative authentication systems especially for high risk accounts. There are several variations on the theme of one-time passwords that I think could bd explored. Pine On Aug 6, 2014 11:05 PM, Brian Wolff bawo...@gmail.com wrote: On Aug 6, 2014 8:57 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything The solution to stolen credentials is to combine all credentials so that a single credential can control everything? --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
UnicornPI (unicorn-pie) sounds good to me ;) On 8/7/14, Brandon Harris bhar...@wikimedia.org wrote: something something Unicorn. On Aug 6, 2014, at 2:32 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: When api.php was basically the only API in MediaWiki, calling it the API worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying the API is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like the api.php API. I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
Mmmm, Unicorn Pie. Now I'm hungry. -Chad On Thu, Aug 7, 2014 at 10:37 AM, Amir Ladsgroup ladsgr...@gmail.com wrote: UnicornPI (unicorn-pie) sounds good to me ;) On 8/7/14, Brandon Harris bhar...@wikimedia.org wrote: something something Unicorn. On Aug 6, 2014, at 2:32 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: When api.php was basically the only API in MediaWiki, calling it the API worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying the API is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like the api.php API. I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thu, Aug 7, 2014 at 9:49 AM, Risker risker...@gmail.com wrote: As someone with one of those high risk accounts, one time passwords would be more likely to make me drop those permissions. Any administrator has a high risk account given the opportunities that they have. Risker/Anne +1. I'm lazy and wouldn't want the burden of remembering more than password123 as my password (same password I use everywhere, again, I'm lazy) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thursday, August 7, 2014, Brian Wolff bawo...@gmail.com wrote: Do you have anything specific in mind? Hard to say how feasible something is/evaluate without being more specific. Most non-password alternatives that I can think of (e.g. Having public private key pairs or something) have the problem that they can't really be integrated well enough into a web browser based environment that folks other than the most technical of users find them an acceptable burden. --bawolff I've long wondered about that. Are there really no browser based public key based solutions? Are there any fundamental reasons why that is like that other than that it never got implemented, or never became popular? It seems like the right solution for the password problem. -Martijn On 8/7/14, Pine W wiki.p...@gmail.com javascript:; wrote: I think we should start looking at alternative authentication systems especially for high risk accounts. There are several variations on the theme of one-time passwords that I think could bd explored. Pine On Aug 6, 2014 11:05 PM, Brian Wolff bawo...@gmail.com javascript:; wrote: On Aug 6, 2014 8:57 AM, svetlana svetl...@fastmail.com.au javascript:; wrote: On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything The solution to stolen credentials is to combine all credentials so that a single credential can control everything? --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On 07/08/14 02:37, MZMcBride wrote:
A quick count at https://www.mediawiki.org/w/api.php says that there are
currently 52 list=foo entries and 83 action=foo entries. While these
numbers are inflated due to installed extensions, I'm hesitant to present
the MediaWiki Web API as an action API. Though you could perhaps argue
that listing is just another action.
Like Daniel said, what you call listing is actually the query action.
I tend to agree with the view of others in this thread that simply saying
the [{MediaWiki (core), Web}] API is usually sufficiently clear.
Note that Nemo bis changed the name from MediaWiki API to WebAPI
on the basis of disambiguation, in this revision:
https://www.mediawiki.org/w/index.php?title=API:Main_pagediff=644948oldid=642646
I have previously suggested web API as a term to distinguish it from
the set of PHP classes and hooks used by extensions. API stands for
application programmer interface, and traditionally refers to
functions and classes -- using the term for a non-RPC HTTP interface
is really rather awkward.
Neither MediaWiki API nor Web API distinguishes it from the
proposed REST API. For someone using api.php every day, the API is
clear enough, but if you are a mobile developer using the REST API
every day, you need some other term to specify api.php.
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thu, 7 Aug 2014, at 19:50, Martijn Hoekstra wrote: On Thursday, August 7, 2014, Brian Wolff bawo...@gmail.com wrote: Do you have anything specific in mind? Hard to say how feasible something is/evaluate without being more specific. Most non-password alternatives that I can think of (e.g. Having public private key pairs or something) have the problem that they can't really be integrated well enough into a web browser based environment that folks other than the most technical of users find them an acceptable burden. --bawolff I've long wondered about that. Are there really no browser based public key based solutions? [...] -Martijn certfp authentication ? ex. https://freenode.net/certfp/certfp-chatzilla.shtml svetlana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
but if you are a mobile developer using the REST API every day, you need some other term to specify api.php. Is api.php unsuitable for some reason? - d ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On Thu, Aug 7, 2014 at 10:58 AM, David Gerard dger...@gmail.com wrote: but if you are a mobile developer using the REST API every day, you need some other term to specify api.php. Is api.php unsuitable for some reason? That itself is awkward to say, and to disambiguate between the actual file and the API accessed via the file the api.php API is even worse. So I started this thread to see if we could come up with something that isn't so awkward. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
I've long wondered about that. Are there really no browser based public key based solutions? Are there any fundamental reasons why that is like that other than that it never got implemented, or never became popular? It seems like the right solution for the password problem. -Martijn I think TLS has a feature where the client can also provide a certificate, in order to use certificates to authenticate users. I've never heard of a site actually using it. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On 7 August 2014 10:49, Chad innocentkil...@gmail.com wrote: On Thu, Aug 7, 2014 at 9:49 AM, Risker risker...@gmail.com wrote: As someone with one of those high risk accounts, one time passwords would be more likely to make me drop those permissions. Any administrator has a high risk account given the opportunities that they have. Risker/Anne +1. I'm lazy and wouldn't want the burden of remembering more than password123 as my password (same password I use everywhere, again, I'm lazy) Oh I have no problem with regular forced password changes, say quarterly or so; I'm used to that in other contexts. But not a one-time password, which will actually increase risk because people will choose keep me logged in to avoid having to get a new password every time they want to log in. These tend also to be solutions coming from moneyed countries, and some of these things involve technology that is not globally available. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
Well if we kill off XML and other funky formats we can call it the JSON API :) -- brion On Thu, Aug 7, 2014 at 11:00 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Thu, Aug 7, 2014 at 10:58 AM, David Gerard dger...@gmail.com wrote: but if you are a mobile developer using the REST API every day, you need some other term to specify api.php. Is api.php unsuitable for some reason? That itself is awkward to say, and to disambiguate between the actual file and the API accessed via the file the api.php API is even worse. So I started this thread to see if we could come up with something that isn't so awkward. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On 7 August 2014 11:23, Brion Vibber bvib...@wikimedia.org wrote: Well if we kill off XML and other funky formats we can call it the JSON API :) Except the other APIs will likely use JSON too, AIUI… :-) J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Aug 7, 2014, at 6:01, Brian Wolff bawo...@gmail.com wrote: I've long wondered about that. Are there really no browser based public key based solutions? Are there any fundamental reasons why that is like that other than that it never got implemented, or never became popular? It seems like the right solution for the password problem. -Martijn I think TLS has a feature where the client can also provide a certificate, in order to use certificates to authenticate users. I've never heard of a site actually using it. I'd have to research the particulars, but I've seen many government/corporate sites use TLS for user authentication with the Apache HTTP Server or JBoss. I know we bounced the client certs off of CAs and CRLs on the server for authentication, but don't remember how we shared the distinguished name (DN) with the higher level program (e.g. PHP) for authorization. I'll see what I can find. --Shawn ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On Wed, Aug 6, 2014 at 10:15 PM, James Forrester jdforres...@gmail.com wrote: Yes, this is sensible. Let's certainly not call it the MediaWiki API given how many are planned. Core seems a reasonable qualifier, though, no? Seems like the content API and a lot of other proposed interfaces are by definition outside the core. So why not MW core API or just core API for short? -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
Hm... and I am a lazy hacker, so now when you told us your password, could you please give me your username as well so that I don't have to search it? Thanks! :P On Thu, Aug 7, 2014 at 11:49 AM, Chad innocentkil...@gmail.com wrote: I'm lazy and wouldn't want the burden of remembering more than password123 as my password (same password I use everywhere, again, I'm lazy) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
nevermind, I just figured out that I can edit almost anything on wikipedia even without password... what a hacker am I! BTW: those with high-risk accounts should use strong passwords, which could be very safe at some point. I once suggested some security enhancements that wouldn't impact users at all, but they weren't supported much with reason that sounded to me like nobody cares about security on projects like wikipedia On Thu, Aug 7, 2014 at 12:59 PM, Petr Bena benap...@gmail.com wrote: Hm... and I am a lazy hacker, so now when you told us your password, could you please give me your username as well so that I don't have to search it? Thanks! :P On Thu, Aug 7, 2014 at 11:49 AM, Chad innocentkil...@gmail.com wrote: I'm lazy and wouldn't want the burden of remembering more than password123 as my password (same password I use everywhere, again, I'm lazy) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
Oh I have no problem with regular forced password changes, say quarterly or so; I'm used to that in other contexts. But not a one-time password, which will actually increase risk because people will choose keep me logged in to avoid having to get a new password every time they want to log in. I believe there's some research to suggest that quarterly password changes decrease overall security. I personally would not like having to do that. These tend also to be solutions coming from moneyed countries, and some of these things involve technology that is not globally available. I'm not sure what you mean by that. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
Core API can be misleading since people may think other APIs are based on MW's API (i.e. It's core of other APIs) even though It's true in some cases but not necessarily for all. Am I wrong? Best On 8/7/14, Erik Moeller e...@wikimedia.org wrote: On Wed, Aug 6, 2014 at 10:15 PM, James Forrester jdforres...@gmail.com wrote: Yes, this is sensible. Let's certainly not call it the MediaWiki API given how many are planned. Core seems a reasonable qualifier, though, no? Seems like the content API and a lot of other proposed interfaces are by definition outside the core. So why not MW core API or just core API for short? -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On 8/7/14, 10:58 AM, David Gerard wrote: but if you are a mobile developer using the REST API every day, you need some other term to specify api.php. Is api.php unsuitable for some reason? I like api.php too, given that we refer to the old one as query.php. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On 7 August 2014 12:04, Brian Wolff bawo...@gmail.com wrote: Oh I have no problem with regular forced password changes, say quarterly or so; I'm used to that in other contexts. But not a one-time password, which will actually increase risk because people will choose keep me logged in to avoid having to get a new password every time they want to log in. I believe there's some research to suggest that quarterly password changes decrease overall security. I personally would not like having to do that. These tend also to be solutions coming from moneyed countries, and some of these things involve technology that is not globally available. I'm not sure what you mean by that. A lot of the solutions normally bandied about involve things like two-factor identification, which has the additional password coming through a separate route (e.g., gmail two-factor ID sends a second password as a text to a mobile) and means having more expensive technology) or using technology like dongles that cannot be sent to users in certain countries. I stick to my strong passwords and also subscribe to the xkcd password theory.[1] Risker/Anne [1] https://www.xkpasswd.net/c/index.cgi ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
I think a two-way-authentification is the first, good step to increase the security for account authentification, like wikitech still use it. But it's still a user decision to activate i tor not? Freundliche Grüße / Kind regards Florian -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Risker Gesendet: Donnerstag, 7. August 2014 10:50 An: Wikimedia developers Betreff: Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords As someone with one of those high risk accounts, one time passwords would be more likely to make me drop those permissions. Any administrator has a high risk account given the opportunities that they have. Risker/Anne On 7 August 2014 07:59, Pine W wiki.p...@gmail.com wrote: I think we should start looking at alternative authentication systems especially for high risk accounts. There are several variations on the theme of one-time passwords that I think could bd explored. Pine On Aug 6, 2014 11:05 PM, Brian Wolff bawo...@gmail.com wrote: On Aug 6, 2014 8:57 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything The solution to stolen credentials is to combine all credentials so that a single credential can control everything? --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On Thu, Aug 7, 2014 at 7:42 AM, Legoktm legoktm.wikipe...@gmail.com wrote: I like api.php too, given that we refer to the old one as query.php. We should just go back to query.php and get rid of api.php so we can avoid all this confusion. /s *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thu, Aug 7, 2014 at 6:01 AM, Brian Wolff bawo...@gmail.com wrote: I think TLS has a feature where the client can also provide a certificate, in order to use certificates to authenticate users. I've never heard of a site actually using it. Indeed. https://www.mediawiki.org/wiki/Extension:SSLClientAuthentication *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thu, Aug 7, 2014 at 8:10 AM, Risker risker...@gmail.com wrote: A lot of the solutions normally bandied about involve things like two-factor identification, which has the additional password coming through a separate route (e.g., gmail two-factor ID sends a second password as a text to a mobile) and means having more expensive technology) or using technology like dongles that cannot be sent to users in certain countries. Actually, most modern internet implementations use the TOTP algorithm open standard that anyone can use for free. https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm One of the most common methods, other than through text messages, is the Google Authenticator App that anyone can download for free on a smart phone. https://en.wikipedia.org/wiki/Google_Authenticator. I'm not sure we can make any of these extra protections *required* without a lot of discussion, but giving people the option will certainly help. Wikimedians are usually a pretty geeky and paranoid bunch, so I think a good amount of people would take advantage of additional security features. This is especially true given how many people use https://en.wikipedia.org/wiki/Template:User_committed_identity on enwiki, something I've never really understood the point of. :-) -- Casey Brown (Cbrown1023) caseybrown.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
I prefer Bob. On 07/08/14 08:40, Pine W wrote: We could name it in honor of Jimbo. ;) On Aug 7, 2014 1:18 AM, David Gerard dger...@gmail.com wrote: Call it Bob. Bob is always a good name. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thu, Aug 7, 2014 at 6:58 AM, Casey Brown li...@caseybrown.org wrote: On Thu, Aug 7, 2014 at 8:10 AM, Risker risker...@gmail.com wrote: A lot of the solutions normally bandied about involve things like two-factor identification, which has the additional password coming through a separate route (e.g., gmail two-factor ID sends a second password as a text to a mobile) and means having more expensive technology) or using technology like dongles that cannot be sent to users in certain countries. Actually, most modern internet implementations use the TOTP algorithm open standard that anyone can use for free. https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm One of the most common methods, other than through text messages, is the Google Authenticator App that anyone can download for free on a smart phone. https://en.wikipedia.org/wiki/Google_Authenticator. Yep. This. It's already being used for high-risk accounts on wikitech.wikimedia.org. It's not in good enough shape to be used anywhere else, since if you lose your device you'd lose your account. Supporting two factor auth also requires supporting multiple ways to rescue your account if you lose your device (and don't write down your scratch tokens, which is common). Getting this flow to work in a way that actually adds any security benefit is difficult. See the amount of effort Google has gone through for this. Let's be a little real here, though. There's honestly no good reason to target these accounts. There's basically no major damage they can do and there's very little private information accessible to them, so attackers don't really care enough to attack them. We should take basic account security seriously, but we shouldn't go overboard. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
There are good reasons people would target checkuser accounts, WMF staff email accounts, and other accounts that have access to lots of private info like functionary email accounts and accounts with access to restricted IRC channels. Pine On Thu, Aug 7, 2014 at 11:21 AM, Ryan Lane rlan...@gmail.com wrote: On Thu, Aug 7, 2014 at 6:58 AM, Casey Brown li...@caseybrown.org wrote: On Thu, Aug 7, 2014 at 8:10 AM, Risker risker...@gmail.com wrote: A lot of the solutions normally bandied about involve things like two-factor identification, which has the additional password coming through a separate route (e.g., gmail two-factor ID sends a second password as a text to a mobile) and means having more expensive technology) or using technology like dongles that cannot be sent to users in certain countries. Actually, most modern internet implementations use the TOTP algorithm open standard that anyone can use for free. https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm One of the most common methods, other than through text messages, is the Google Authenticator App that anyone can download for free on a smart phone. https://en.wikipedia.org/wiki/Google_Authenticator. Yep. This. It's already being used for high-risk accounts on wikitech.wikimedia.org. It's not in good enough shape to be used anywhere else, since if you lose your device you'd lose your account. Supporting two factor auth also requires supporting multiple ways to rescue your account if you lose your device (and don't write down your scratch tokens, which is common). Getting this flow to work in a way that actually adds any security benefit is difficult. See the amount of effort Google has gone through for this. Let's be a little real here, though. There's honestly no good reason to target these accounts. There's basically no major damage they can do and there's very little private information accessible to them, so attackers don't really care enough to attack them. We should take basic account security seriously, but we shouldn't go overboard. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder. Either that or we might want to put Vector as a submodule? PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update. On Thu, Aug 7, 2014 at 9:18 AM, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Thu, Aug 7, 2014 at 11:27 AM, Pine W wiki.p...@gmail.com wrote: There are good reasons people would target checkuser accounts, WMF staff email accounts, and other accounts that have access to lots of private info like functionary email accounts and accounts with access to restricted IRC channels. WMF uses gmail; they should force-require the use of two factor authentication for their employees if they care about that. Restricted IRC channels also don't have anything to do with Wikimedia wiki account security (and IRC security is a joke anyway, so if we're really relying on that to be secure, shame on us). - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Hmm, now i think about that point: The normal third party user should download the latest build of MediaWiki via the tarball installer [1]. In this packages, Vector (and monobook as well) is still included. So the normal third party user won't see any problem with this. The users normally download MediaWiki from git are developers or persons who want to learn MediaWiki development. And (that's my personal point of view), they can figure out, where to get Vector (or some other skin) from and put it into the installations skin folder. And if i run a composer command or git, sorry, but form e it doesn't really matter if i look at the effort that needs to do this. Just my 2 cents :) [1] https://www.mediawiki.org/wiki/Download Freundliche Grüße / Kind regards Florian -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Jon Robson Gesendet: Donnerstag, 7. August 2014 20:29 An: Wikimedia developers Betreff: Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder. Either that or we might want to put Vector as a submodule? PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update. On Thu, Aug 7, 2014 at 9:18 AM, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Yeh it's also worth pointing out that the installer does this all effortlessly. So this is really only effecting existing users. That said I wonder if someone could make this a more effortless step. If the default fallback skin said 'If you are administrator please run git submodule update' or 'composer install skin-vector' I think the reaction might be more forgiving? On Thu, Aug 7, 2014 at 11:46 AM, Florian Schmidt florian.schmidt.wel...@t-online.de wrote: Hmm, now i think about that point: The normal third party user should download the latest build of MediaWiki via the tarball installer [1]. In this packages, Vector (and monobook as well) is still included. So the normal third party user won't see any problem with this. The users normally download MediaWiki from git are developers or persons who want to learn MediaWiki development. And (that's my personal point of view), they can figure out, where to get Vector (or some other skin) from and put it into the installations skin folder. And if i run a composer command or git, sorry, but form e it doesn't really matter if i look at the effort that needs to do this. Just my 2 cents :) [1] https://www.mediawiki.org/wiki/Download Freundliche Grüße / Kind regards Florian -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Jon Robson Gesendet: Donnerstag, 7. August 2014 20:29 An: Wikimedia developers Betreff: Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder. Either that or we might want to put Vector as a submodule? PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update. On Thu, Aug 7, 2014 at 9:18 AM, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be a pain in the ass. It was to be expected, that there would be some snags. Crying I told you so is somewhat less than constructive. I am sure Bartosz is already working on it. And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it. On 7 August 2014 18:18, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
There are sensitive communications over IRC such as harassment investigations, although hopefully not to the degree that sensitive info goes over email. I use what is advertised as a secure method of accessing IRC, but that is still probably much weaker than end-to-end email encryption. We could look into a more secure messaging system, but my top concern is the security of staff email, Google Docs, staff accounts with access to un-sanitized analytics data. I would start there, followed by Arbcom/CU/OS wiki and email accounts, and probably IRC last. Pine On Thu, Aug 7, 2014 at 11:34 AM, Ryan Lane rlan...@gmail.com wrote: On Thu, Aug 7, 2014 at 11:27 AM, Pine W wiki.p...@gmail.com wrote: There are good reasons people would target checkuser accounts, WMF staff email accounts, and other accounts that have access to lots of private info like functionary email accounts and accounts with access to restricted IRC channels. WMF uses gmail; they should force-require the use of two factor authentication for their employees if they care about that. Restricted IRC channels also don't have anything to do with Wikimedia wiki account security (and IRC security is a joke anyway, so if we're really relying on that to be secure, shame on us). - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Hi, And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience. I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins. Cheers On 8/8/14, Stephan Gambke s7ep...@gmail.com wrote: I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be a pain in the ass. It was to be expected, that there would be some snags. Crying I told you so is somewhat less than constructive. I am sure Bartosz is already working on it. And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it. On 7 August 2014 18:18, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
My staff email is boring. You're more than welcome to break in. -Chad On Aug 7, 2014 7:27 PM, Pine W wiki.p...@gmail.com wrote: There are good reasons people would target checkuser accounts, WMF staff email accounts, and other accounts that have access to lots of private info like functionary email accounts and accounts with access to restricted IRC channels. Pine On Thu, Aug 7, 2014 at 11:21 AM, Ryan Lane rlan...@gmail.com wrote: On Thu, Aug 7, 2014 at 6:58 AM, Casey Brown li...@caseybrown.org wrote: On Thu, Aug 7, 2014 at 8:10 AM, Risker risker...@gmail.com wrote: A lot of the solutions normally bandied about involve things like two-factor identification, which has the additional password coming through a separate route (e.g., gmail two-factor ID sends a second password as a text to a mobile) and means having more expensive technology) or using technology like dongles that cannot be sent to users in certain countries. Actually, most modern internet implementations use the TOTP algorithm open standard that anyone can use for free. https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm One of the most common methods, other than through text messages, is the Google Authenticator App that anyone can download for free on a smart phone. https://en.wikipedia.org/wiki/Google_Authenticator. Yep. This. It's already being used for high-risk accounts on wikitech.wikimedia.org. It's not in good enough shape to be used anywhere else, since if you lose your device you'd lose your account. Supporting two factor auth also requires supporting multiple ways to rescue your account if you lose your device (and don't write down your scratch tokens, which is common). Getting this flow to work in a way that actually adds any security benefit is difficult. See the amount of effort Google has gone through for this. Let's be a little real here, though. There's honestly no good reason to target these accounts. There's basically no major damage they can do and there's very little private information accessible to them, so attackers don't really care enough to attack them. We should take basic account security seriously, but we shouldn't go overboard. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Actually Im not making personal attacks. I am pointing out the flawed process that is being/was implemented. What should have happened was that skins are migrated to extensions and use the existing structure. Doing that would require a lot of work, and a fairly major overhaul of the existing code. Because that is too much work/too complex/users want to take the easy way out the current process was used. Doing something this critical half baked, which was specifically raised before and ignored, is a BAD idea. I know quite a few users who use GIT checkouts for their wikis. Guess what? this change will screw all of them and be a pain in the ass to fix and maintain such forking. Moving to an extension based system is the correct, logical and long term best solution. But you know what? it wont happen, instead skins will fork into a spaghetti code system that stifles users who want custom skins and causes a LOT more regression/bugs due to divergent code bases. Ill repeat what I said (knowing it will probably be ignored) If your going to overhaul the skin system do it right and merge them into the existing extension framework dont re-invent the wheel and add more overhead to an already complex system. On Thu, Aug 7, 2014 at 3:12 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience. I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins. Cheers On 8/8/14, Stephan Gambke s7ep...@gmail.com wrote: I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be a pain in the ass. It was to be expected, that there would be some snags. Crying I told you so is somewhat less than constructive. I am sure Bartosz is already working on it. And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it. On 7 August 2014 18:18, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
John, switching to extension based skins would have resulted in this EXACT same scenario. Since the only difference here is that the skins are in skins/ instead of extensions/. In both cases the vanilla core git repo would not have the skin checked out and you would still have to clone it in exactly the same way. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] On 2014-08-07, 12:30 PM, John wrote: Actually Im not making personal attacks. I am pointing out the flawed process that is being/was implemented. What should have happened was that skins are migrated to extensions and use the existing structure. Doing that would require a lot of work, and a fairly major overhaul of the existing code. Because that is too much work/too complex/users want to take the easy way out the current process was used. Doing something this critical half baked, which was specifically raised before and ignored, is a BAD idea. I know quite a few users who use GIT checkouts for their wikis. Guess what? this change will screw all of them and be a pain in the ass to fix and maintain such forking. Moving to an extension based system is the correct, logical and long term best solution. But you know what? it wont happen, instead skins will fork into a spaghetti code system that stifles users who want custom skins and causes a LOT more regression/bugs due to divergent code bases. Ill repeat what I said (knowing it will probably be ignored) If your going to overhaul the skin system do it right and merge them into the existing extension framework dont re-invent the wheel and add more overhead to an already complex system. On Thu, Aug 7, 2014 at 3:12 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience. I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins. Cheers On 8/8/14, Stephan Gambke s7ep...@gmail.com wrote: I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be a pain in the ass. It was to be expected, that there would be some snags. Crying I told you so is somewhat less than constructive. I am sure Bartosz is already working on it. And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really? Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it. On 7 August 2014 18:18, John phoenixoverr...@gmail.com wrote: Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted. On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about mediawiki/skins/* at all. Cheers On 8/7/14, Bartosz Dziewoński matma@gmail.com wrote: This has just happened. The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On 07-08-2014 16:32, Bartosz Dziewoński wrote: This has just happened. This is bad. I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch. I now have to submit two patches and hope they both get merged at the exact same time. I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository. Regards, -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
But extensions have the exact same problem. Normally then you first prepare core functions and then change the skin itself (maybe with two patches at the same time referring to each other). So the core patch is merged before the skin patch. It's more work for Vector skin, yes, but i want to ask (really, i don't know this fact): How often this happens? Freundliche Grüße / Kind regards Florian -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Erwin Dokter Gesendet: Donnerstag, 7. August 2014 22:06 An: Wikimedia developers Betreff: Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you On 07-08-2014 16:32, Bartosz Dziewoński wrote: This has just happened. This is bad. I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch. I now have to submit two patches and hope they both get merged at the exact same time. I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository. Regards, -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Can we have a note in the installer where it says that skin is missing -- that it has to be included like other extensions with require_once($IP/skins/Vector.php); On Thu, Aug 7, 2014 at 1:05 PM, Erwin Dokter er...@darcoury.nl wrote: On 07-08-2014 16:32, Bartosz Dziewoński wrote: This has just happened. This is bad. I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch. I now have to submit two patches and hope they both get merged at the exact same time. I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository. Regards, -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Lojjik L. Braughler B.S., Computer Science/Applied Indiana University of Pennsylvania, 2017 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords
On Wed, Aug 6, 2014 at 8:26 AM, Tyler Romeo tylerro...@gmail.com wrote: In terms of external authentication, we need Extension:OpenID to catch up to the OpenID standard in order to do that. In terms of two-factor, I have like eight patches for Extension:OATHAuth attempting to make it production-worthy. https://gerrit.wikimedia.org/r/132783 Nice! I hadn't realized you had got so far on this. Maybe Ryan and I can get those merged in... To address Risker's comment, OATH is an open standard with lots of tools to generate the tokens, so you can use a secure token if you want to be more secure, or a browser plugin if you're just worried about someone stealing your password (which would significantly help our threat model in countries where we can't force https). Client TLS certificates are sadly really hard to manage in any sort of secure way, when you don't control the end user's machines. -- Tyler Romeo 0x405D34A7C86B42DF From: svetlana svetl...@fastmail.com.au Reply: Wikimedia developers wikitech-l@lists.wikimedia.org Date: August 6, 2014 at 7:57:12 To: wikitech-l@lists.wikimedia.org wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote: On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote: After reading this [1] I am wondering if Wikimedia should start taking steps to reduce reliance on usernames and passwords. What steps do you refer to, or is this intentionally vague? Disallowing usernames and logins? Two-step authentication/verification? Something else? andre from what i could read and parse: use less of external things like skype and google accounts so that there is only 1 username for everything ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
On Thu, Aug 7, 2014 at 1:42 PM, Legoktm legoktm.wikipe...@gmail.com wrote: I like api.php too, given that we refer to the old one as query.php. You are in a keynote session at OSCON introducing... which API? Please think on a name that is meaningful for the 3rd party developers out there, not just for you. api.php alone won't work. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On Thu, 07 Aug 2014 18:02:58 +0200, James HK jamesin.hongkon...@gmail.com wrote: Hi, I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available. I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be. I do expect when downloading MW it is at least functional and not comes with a message of Whoops! your missing something. On Thu, 07 Aug 2014 21:12:13 +0200, James HK jamesin.hongkon...@gmail.com wrote: Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience. I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins. If you want a stable experience, it is unwise to use the git master to run your wiki. I recommend using the tarballs or checking out release branches. Straight git master checkout *is* functional; it includes the minimal skin that you're seeing that also displays a (hopefully useful) information screen. If you have concrete suggestions on how to improve that message, I'd love to hear them. I am sad to have introduced a breaking change, but these are sometimes necessary. I tried to make the transition as painless as possible. Again, I'd love to hear concrete improvement suggestions. The other funny thing, is the message which says: You can paste the following lines into LocalSettings.php to enable all currently installed skins: ( empty ) So I should paste an empty message to `LocalSettings.php`, what the hell!! That's interesting. Can you share any details about your personal setup, so that I can try to debug this? I have tested this and my MediaWiki installation correctly produces a message that you have no skins installed. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On Thu, 07 Aug 2014 20:46:28 +0200, Florian Schmidt florian.schmidt.wel...@t-online.de wrote: Hmm, now i think about that point: The normal third party user should download the latest build of MediaWiki via the tarball installer [1]. In this packages, Vector (and monobook as well) is still included. So the normal third party user won't see any problem with this. The users normally download MediaWiki from git are developers or persons who want to learn MediaWiki development. And (that's my personal point of view), they can figure out, where to get Vector (or some other skin) from and put it into the installations skin folder. And if i run a composer command or git, sorry, but form e it doesn't really matter if i look at the effort that needs to do this. Indeed, that was my thinking. Developers can also use MediaWiki-Vagrant which has already been updated to handle the new way of including skins (3 Gergő and Bryan). [1] https://gerrit.wikimedia.org/r/#/c/152828/ -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On Thu, 07 Aug 2014 22:05:53 +0200, Erwin Dokter er...@darcoury.nl wrote: On 07-08-2014 16:32, Bartosz Dziewoński wrote: This has just happened. This is bad. I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch. I now have to submit two patches and hope they both get merged at the exact same time. I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository. I actually consider this a positive change. Hopefully this will result in fewer unnecessary breaking changes in core skin interfaces, and thus less pain during MediaWiki upgrade for site administrators. When it is actually necessary to make a breaking change and update the skins, it's not a big problem to synchronise it – if you describe the dependencies in the commit message, you can trust that the people with +2 rights will be smart enough to handle it, really. Feel free to poke me about any such changes. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On Thu, 07 Aug 2014 22:20:15 +0200, Lojjik L. Braughler llbraugh...@gmail.com wrote: Can we have a note in the installer where it says that skin is missing -- that it has to be included like other extensions with require_once($IP/skins/Vector.php); The installer handles skin differently and this change doesn't cause any problems for it. (There is a set of checked-by-default checkboxes for every available skin during installation.) Assuming you meant the fallback skin displaying the warning message, it should already display such a message if there is any skin available to be enabled (otherwise it will display general installation instructions). Does that not work for you? -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Just using a straight master checkout and had the same LocalSettings, default skin Vector wasn't found and had to check it in to my skins folder. But I wasn't aware at first that it had to be included with a require_once() statement because the message didn't state it. Not a big deal though, I found it eventually :P. On Thu, Aug 7, 2014 at 5:09 PM, Bartosz Dziewoński matma@gmail.com wrote: On Thu, 07 Aug 2014 22:20:15 +0200, Lojjik L. Braughler llbraugh...@gmail.com wrote: Can we have a note in the installer where it says that skin is missing -- that it has to be included like other extensions with require_once($IP/skins/Vector.php); The installer handles skin differently and this change doesn't cause any problems for it. (There is a set of checked-by-default checkboxes for every available skin during installation.) Assuming you meant the fallback skin displaying the warning message, it should already display such a message if there is any skin available to be enabled (otherwise it will display general installation instructions). Does that not work for you? -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Lojjik L. Braughler B.S., Computer Science/Applied Indiana University of Pennsylvania, 2017 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
