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.
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,
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
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
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
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
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
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
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
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
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,
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.
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
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.
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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:
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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,
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
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
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
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
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
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
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
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,
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
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
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
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
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
59 matches
Mail list logo
