Re: [Wikitech-l] OAuth and Identities

[MZMcBride]

Petr Bena wrote:
>Do you realize that these application are asking users for their
>password in this moment? That seems to me even worse than oauth with
>these "caviots"

Which applications are asking users for their password?

The only partial example I can come up with off-hand is AutoWikiBrowser,
though I believe that passed the credentials through Internet Explorer or
something and then only used the cookies/session? I'm not sure it stores
the username and password directly, though it's been a long time since
I've used it and I certainly can't say for sure.

I'd be interested to know which applications you're referring to.

MZMcBride

P.S. s/caviot/caveat/ :-)



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] mw.inspect: new CSS report

[Ori Livneh]

Running mw.loader.inspect('css') in a JavaScript console will now
report CSS stats for each active ResourceLoader style module,
including the total count of selectors and the percentage of those
that match some node in the current DOM.

---
Ori Livneh
o...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] HTTP Archive now tracking several Wikimedia wikis

[Ori Livneh]

The HTTP Archive () audits the setup and
performance of popular websites, reporting things like load times,
download sizes, performance scores, waterfall charts, and cache
headers. They provide per-site reports as well as aggregate data about
trends in web technology.

They added several Wikimedia wikis to their index last month and the
first two reports (dated Oct 1 and Oct 15) are available. The reports
for the desktop site of the English Wikipedia are available here:
.

(I do not expect to see much variation across Wikimedia wikis, since
they are co-hosted on the same infrastructure.)

There's a wealth of data available. It should help us assess how we're
doing relative to other sites and where we need to improve. I plan on
studying this data on an ongoing basis and I invite / encourage you to
do the same. Be sure to share your discoveries with this list.

---
Ori Livneh
o...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Redirects from Commons to wikimediafoundation

[Daniel Zahn]

Hi,

here's a more detailed report:

As part of an ongoing effort to simplify, cleanup and reduce code lines of
the Apache cluster config,
we we're planning to unify a lot of document roots for the "www"-portals
into a single docroot, like here:

https://gerrit.wikimedia.org/r/#/c/90669/

looking at that we saw that the www.wikimedia.org portal wasn't handled by
this, unlike the other portals, so
to further unify this we merged:

https://gerrit.wikimedia.org/r/#/c/91195/

which "just" moved the existing config for www.wikimedia.org to the
wwwportals.conf file.

But because this had an old " ServerAlias *.wikimedia.org" in it, which now
changed in the order Apache goes through the config,
it caused *.wikimedia.org URLs to redirect to wikimediafoundation.org

..
ServerAlias *.wikimedia.org
..
RewriteRule ^/wiki/(.*)$ http://wikimediafoundation.org/wiki/$1 [R=301,L]

We reverted both of the recent changes after just a few minutes and synced
Apache config and restarted them.

Users still reported problems though due to caching.  So we started some
Squid purging and  Mark banned php content-type in varnish.

Additionally it turned out several Apaches didn't get restarted properly by
apache-graceful-all,  and using apache-fast-test  with the pybal option we
found some more that needed manual restarts a little while later.

For futher fixes Brandon banned by object size:  did < bblack> !log
varnish: banned 'obj.http.content-length == 33518' on text varnishes
everywhere (extract2.php leakage).
.. Reedy already prepared new patches to fix the root cause
..and apache-fast-test should check eqiad now instead of Tampa:
https://gerrit.wikimedia.org/r/#/c/91270/

Sorry for breakage! Thank you for help!


-- 
Daniel Zahn 
Operations Engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Redirects from Commons to wikimediafoundation

[Bartosz Dziewoński]

https://bugzilla.wikimedia.org/show_bug.cgi?id=56006

Almost completely fixed now, there are some cached things that have to be 
purged.

--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] input requested re: metrics for hackathons

[Jonathan Morgan]

Hi all,

OrenBachman has asked several questions about how to evaluate the impact of
Hackathon events on the Evaluation Portal*[1]* and I'm hoping some folks
from this list can share their advice and perspectives.

Please read and respond there if you have input. Several outstanding
questions are:

1. do you know of any available publicly stats on how many first time
MediaWiki hackers make use of git/gerrit?

2. can you share any good strategies for getting as many attendees as
possible to set up git/gerrit userids prior to the event?

3. can you provide any examples of reports from previous Hackathons that do
a good job of describing various impact/participation metrics?

4. Safe space policy - How have breaches to the safe space policy been
handled in recent events? How have they been reported?

I'm going to follow up elsewhere about the legal issues OrenBachman raises,
but feel free to share your experiences with those as well.

Thanks for your assistance,
Jonathan

*[1]*
https://meta.wikimedia.org/wiki/Programs:Evaluation_portal/Parlor/Questions#What_are_the_established_Goals_and_Metrics_used_to_evaluate_Hackathons

-- 
Jonathan T. Morgan
Learning Strategist
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Redirects from Commons to wikimediafoundation

[Brion Vibber]

I believe there was a configuration error this morning which got some
redirects stuck in cache; they should be on the way to being fixed...

-- brion


On Tue, Oct 22, 2013 at 11:56 AM, Eugene Zelenko
wrote:

> Hi!
>
> I experienced weird problem today when accessing Commons (addresses
> like https://commons.wikimedia.org/wiki/Special:Watchlist and
> http://commopns.wikimedia.org/wiki/Category:Yuri_Gagarin): I was
> redirected to same pages on http://wikimediafoundation.org.
>
> Eugene.
>
> ___
> 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] Redirects from Commons to wikimediafoundation

[Eugene Zelenko]

Hi!

I experienced weird problem today when accessing Commons (addresses
like https://commons.wikimedia.org/wiki/Special:Watchlist and
http://commopns.wikimedia.org/wiki/Category:Yuri_Gagarin): I was
redirected to same pages on http://wikimediafoundation.org.

Eugene.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth and Identities

[Petr Bena]

Do you realize that these application are asking users for their
password in this moment? That seems to me even worse than oauth with
these "caviots"

On Tue, Oct 22, 2013 at 7:54 PM, Chris Steipp  wrote:
> On Tue, Oct 22, 2013 at 10:33 AM, Petr Bena  wrote:
>
>> I am basically interested only in oauth that can be used by remote
>> applications / processes running on user's PC, which isn't available
>> yet
>>
>
> This is the second most requested feature that we don't support yet.
>
> We've been looking at options for it. All solutions would basically require
> we make a second class of OAuth Consumers. This has precedence: OAuth 2
> makes the distinction between "confidential" and "public" consumers, and
> Twitter's xAuth has to be specifically enabled on your OAuth Consumer.
> We're debating making a similar distinction for our OAuth Consumers, but we
> don't want to get into the situation where we need to give lots of caviots
> to our users that, "Yes, this OAuth thing is secure, as long as Consumers
> of this type are doing these things, but these other ones also need to do
> these other things...".
>
>
>>
>> On Tue, Oct 22, 2013 at 7:18 PM, Chris Steipp 
>> wrote:
>> > On Tue, Oct 22, 2013 at 1:57 AM, Merlijn van Deen > >wrote:
>> >
>> >> Hi Chris,
>> >>
>> >> On 22 October 2013 05:45, Chris Steipp  wrote:
>> >>
>> >> > OAuth does not support this, since the results of an api call
>> >> > using OAuth signatures aren't signed (only the request from the OAuth
>> >> > consumer is signed), so it's possible that an attacker could forge a
>> >> > response back to the application, and the application would think a
>> >> > different user was logged in. This is less likely if you're using
>> https
>> >> for
>> >> > your api calls, but it's surprisingly hard to get https right [1],
>> even
>> >> if
>> >> > you trust all your CA's.
>> >> >
>> >> (...)
>> >>
>> >> >
>> >> > This is a common issue is being addressed by the OpenID Connect
>> extension
>> >> > to OAuth2, which allows the application to request information about
>> the
>> >> > person doing the authorization, and the result is signed by the
>> server to
>> >> > prevent tampering.
>> >>
>> >> (...)
>> >>
>> >> I'm a bit confused by this -- I was under the impression https would be
>> >> enough to confirm I'm actually talking to the WMF's servers. The main
>> >> argument in [1] against just using https seems to be it's easy to ignore
>> >> invalid certificates. Is there another reason why it's dangerous to
>> assume
>> >> you're talking to mw.o if the certificates check out?
>> >>
>> >
>> > That's correct. The issue is more that we (the security community) keep
>> > finding code out there that doesn't correctly handle the verification (
>> > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf was one of the popular
>> > surveys of the subject). It's often the underlying libraries at fault
>> > (errors parsing the certificates, or the revocation lists, that fail
>> open),
>> > or common programming mistakes (like how mediawiki
>> > set CURLOPT_SSL_VERIFYHOST to true, instead of 2, for a very long time).
>> > But if you accept that your current libraries are probably flawed, and so
>> > you keep your libraries up to date, and you're careful about how you're
>> > doing the verification at the application layer, you *should* be fine.
>> >
>> >
>> >>
>> >> Basically, I'm not quite sure whether using OIDC will help alleviate
>> this
>> >> problem - you get a response back, but you still have to check the
>> >> signature! And with the ease of not checking the signature, you're
>> >> basically back to the same problem with not checking the ssl
>> certificate.
>> >>
>> >
>> > Correct. Hopefully, applications that really need to know the identity
>> of a
>> > user (like UTRS) will go through the bother of checking the signature (in
>> > both OpenID Connect, and the intermediate solution I'm proposing, this is
>> > an HMAC signature using a pre-established secret, so it should be easy
>> > enough that the effort is worth the security).
>> >
>> >
>> >>
>> >> Nonetheless, I think it's useful to add an authentication mechanism that
>> >> follows a standard - which is clearly not the case with the current
>> >> 'api.php?meta=userinfo' calls.
>> >>
>> >> Merlijn
>> >>
>> >> [1]
>> >>
>> >>
>> http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/
>> >> ___
>> >> 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 

Re: [Wikitech-l] OAuth and Identities

[Chris Steipp]

On Tue, Oct 22, 2013 at 10:33 AM, Petr Bena  wrote:

> I am basically interested only in oauth that can be used by remote
> applications / processes running on user's PC, which isn't available
> yet
>

This is the second most requested feature that we don't support yet.

We've been looking at options for it. All solutions would basically require
we make a second class of OAuth Consumers. This has precedence: OAuth 2
makes the distinction between "confidential" and "public" consumers, and
Twitter's xAuth has to be specifically enabled on your OAuth Consumer.
We're debating making a similar distinction for our OAuth Consumers, but we
don't want to get into the situation where we need to give lots of caviots
to our users that, "Yes, this OAuth thing is secure, as long as Consumers
of this type are doing these things, but these other ones also need to do
these other things...".


>
> On Tue, Oct 22, 2013 at 7:18 PM, Chris Steipp 
> wrote:
> > On Tue, Oct 22, 2013 at 1:57 AM, Merlijn van Deen  >wrote:
> >
> >> Hi Chris,
> >>
> >> On 22 October 2013 05:45, Chris Steipp  wrote:
> >>
> >> > OAuth does not support this, since the results of an api call
> >> > using OAuth signatures aren't signed (only the request from the OAuth
> >> > consumer is signed), so it's possible that an attacker could forge a
> >> > response back to the application, and the application would think a
> >> > different user was logged in. This is less likely if you're using
> https
> >> for
> >> > your api calls, but it's surprisingly hard to get https right [1],
> even
> >> if
> >> > you trust all your CA's.
> >> >
> >> (...)
> >>
> >> >
> >> > This is a common issue is being addressed by the OpenID Connect
> extension
> >> > to OAuth2, which allows the application to request information about
> the
> >> > person doing the authorization, and the result is signed by the
> server to
> >> > prevent tampering.
> >>
> >> (...)
> >>
> >> I'm a bit confused by this -- I was under the impression https would be
> >> enough to confirm I'm actually talking to the WMF's servers. The main
> >> argument in [1] against just using https seems to be it's easy to ignore
> >> invalid certificates. Is there another reason why it's dangerous to
> assume
> >> you're talking to mw.o if the certificates check out?
> >>
> >
> > That's correct. The issue is more that we (the security community) keep
> > finding code out there that doesn't correctly handle the verification (
> > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf was one of the popular
> > surveys of the subject). It's often the underlying libraries at fault
> > (errors parsing the certificates, or the revocation lists, that fail
> open),
> > or common programming mistakes (like how mediawiki
> > set CURLOPT_SSL_VERIFYHOST to true, instead of 2, for a very long time).
> > But if you accept that your current libraries are probably flawed, and so
> > you keep your libraries up to date, and you're careful about how you're
> > doing the verification at the application layer, you *should* be fine.
> >
> >
> >>
> >> Basically, I'm not quite sure whether using OIDC will help alleviate
> this
> >> problem - you get a response back, but you still have to check the
> >> signature! And with the ease of not checking the signature, you're
> >> basically back to the same problem with not checking the ssl
> certificate.
> >>
> >
> > Correct. Hopefully, applications that really need to know the identity
> of a
> > user (like UTRS) will go through the bother of checking the signature (in
> > both OpenID Connect, and the intermediate solution I'm proposing, this is
> > an HMAC signature using a pre-established secret, so it should be easy
> > enough that the effort is worth the security).
> >
> >
> >>
> >> Nonetheless, I think it's useful to add an authentication mechanism that
> >> follows a standard - which is clearly not the case with the current
> >> 'api.php?meta=userinfo' calls.
> >>
> >> Merlijn
> >>
> >> [1]
> >>
> >>
> http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/
> >> ___
> >> 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] OAuth and Identities

[Petr Bena]

I am basically interested only in oauth that can be used by remote
applications / processes running on user's PC, which isn't available
yet

On Tue, Oct 22, 2013 at 7:18 PM, Chris Steipp  wrote:
> On Tue, Oct 22, 2013 at 1:57 AM, Merlijn van Deen wrote:
>
>> Hi Chris,
>>
>> On 22 October 2013 05:45, Chris Steipp  wrote:
>>
>> > OAuth does not support this, since the results of an api call
>> > using OAuth signatures aren't signed (only the request from the OAuth
>> > consumer is signed), so it's possible that an attacker could forge a
>> > response back to the application, and the application would think a
>> > different user was logged in. This is less likely if you're using https
>> for
>> > your api calls, but it's surprisingly hard to get https right [1], even
>> if
>> > you trust all your CA's.
>> >
>> (...)
>>
>> >
>> > This is a common issue is being addressed by the OpenID Connect extension
>> > to OAuth2, which allows the application to request information about the
>> > person doing the authorization, and the result is signed by the server to
>> > prevent tampering.
>>
>> (...)
>>
>> I'm a bit confused by this -- I was under the impression https would be
>> enough to confirm I'm actually talking to the WMF's servers. The main
>> argument in [1] against just using https seems to be it's easy to ignore
>> invalid certificates. Is there another reason why it's dangerous to assume
>> you're talking to mw.o if the certificates check out?
>>
>
> That's correct. The issue is more that we (the security community) keep
> finding code out there that doesn't correctly handle the verification (
> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf was one of the popular
> surveys of the subject). It's often the underlying libraries at fault
> (errors parsing the certificates, or the revocation lists, that fail open),
> or common programming mistakes (like how mediawiki
> set CURLOPT_SSL_VERIFYHOST to true, instead of 2, for a very long time).
> But if you accept that your current libraries are probably flawed, and so
> you keep your libraries up to date, and you're careful about how you're
> doing the verification at the application layer, you *should* be fine.
>
>
>>
>> Basically, I'm not quite sure whether using OIDC will help alleviate this
>> problem - you get a response back, but you still have to check the
>> signature! And with the ease of not checking the signature, you're
>> basically back to the same problem with not checking the ssl certificate.
>>
>
> Correct. Hopefully, applications that really need to know the identity of a
> user (like UTRS) will go through the bother of checking the signature (in
> both OpenID Connect, and the intermediate solution I'm proposing, this is
> an HMAC signature using a pre-established secret, so it should be easy
> enough that the effort is worth the security).
>
>
>>
>> Nonetheless, I think it's useful to add an authentication mechanism that
>> follows a standard - which is clearly not the case with the current
>> 'api.php?meta=userinfo' calls.
>>
>> Merlijn
>>
>> [1]
>>
>> http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/
>> ___
>> 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] OAuth and Identities

[Chris Steipp]

On Tue, Oct 22, 2013 at 1:57 AM, Merlijn van Deen wrote:

> Hi Chris,
>
> On 22 October 2013 05:45, Chris Steipp  wrote:
>
> > OAuth does not support this, since the results of an api call
> > using OAuth signatures aren't signed (only the request from the OAuth
> > consumer is signed), so it's possible that an attacker could forge a
> > response back to the application, and the application would think a
> > different user was logged in. This is less likely if you're using https
> for
> > your api calls, but it's surprisingly hard to get https right [1], even
> if
> > you trust all your CA's.
> >
> (...)
>
> >
> > This is a common issue is being addressed by the OpenID Connect extension
> > to OAuth2, which allows the application to request information about the
> > person doing the authorization, and the result is signed by the server to
> > prevent tampering.
>
> (...)
>
> I'm a bit confused by this -- I was under the impression https would be
> enough to confirm I'm actually talking to the WMF's servers. The main
> argument in [1] against just using https seems to be it's easy to ignore
> invalid certificates. Is there another reason why it's dangerous to assume
> you're talking to mw.o if the certificates check out?
>

That's correct. The issue is more that we (the security community) keep
finding code out there that doesn't correctly handle the verification (
http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf was one of the popular
surveys of the subject). It's often the underlying libraries at fault
(errors parsing the certificates, or the revocation lists, that fail open),
or common programming mistakes (like how mediawiki
set CURLOPT_SSL_VERIFYHOST to true, instead of 2, for a very long time).
But if you accept that your current libraries are probably flawed, and so
you keep your libraries up to date, and you're careful about how you're
doing the verification at the application layer, you *should* be fine.


>
> Basically, I'm not quite sure whether using OIDC will help alleviate this
> problem - you get a response back, but you still have to check the
> signature! And with the ease of not checking the signature, you're
> basically back to the same problem with not checking the ssl certificate.
>

Correct. Hopefully, applications that really need to know the identity of a
user (like UTRS) will go through the bother of checking the signature (in
both OpenID Connect, and the intermediate solution I'm proposing, this is
an HMAC signature using a pre-established secret, so it should be easy
enough that the effort is worth the security).


>
> Nonetheless, I think it's useful to add an authentication mechanism that
> follows a standard - which is clearly not the case with the current
> 'api.php?meta=userinfo' calls.
>
> Merlijn
>
> [1]
>
> http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/
> ___
> 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] OAuth and Identities

[Gabriel Wicke]

On 10/21/2013 08:45 PM, Chris Steipp wrote:
> Hi all,
> 
> I wanted to get some input from you all about any ideas or plans they have
> for identifying OAuth user in your applications.
> tl;dr, Since lots of people want to do authentication with OAuth, I'm
> thinking we'll implement a custom way to get identity information from the
> wiki in the near term, and then probably try to implement the OpenID
> Connect extension to OAuth 2 sometime next year.

+1. I especially like the part about being able to verify signed
assertions and identity without hitting the DB, which is very useful for
high-volume APIs.

> Does this seem like a reasonable tradeoff? Assuming we do this direction,
> what attributes about the wiki user account should be provided. I was
> planning on username, if the account is autoconfirmed, maybe number of
> edits, and the list of groups to which the user belongs. Anything else?

It would be great if the JWT could carry the same authorization info as
is retrieved from the DB in OAuth 1. I'm especially interested in
knowing whether a user can read, edit etc a given wiki page, whether it
is a bot account etc. We could perhaps derive this information from a
list of groups by exposing the per-group rights through an internal JSON
API and then expanding groups to rights in an API end point using that
information.

Gabriel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New git-review lets you configure 'origin' as the gerrit remote

[Željko Filipin]

This was working great for me on several machines, but it did not work on
one machine[1][2].

Adding something like this to git-review.conf fixes the problem:

[updates]
check=off

Željko
--
1: https://bugzilla.wikimedia.org/show_bug.cgi?id=55732
2: https://bugs.launchpad.net/git-review/+bug/1243044


On Sat, Jun 1, 2013 at 12:14 AM, Ori Livneh  wrote:

> Hey,
>
> The new version of git-review released today (1.22) includes a patch I
> wrote that makes it possible to work against a single 'origin' remote. This
> amounts to a workaround for git-review's tendency to frighten you into
> thinking you're about to submit more patches than the ones you are working
> on. It makes git-review more pleasant to work with, in my opinion.
>
> To enable this behavior, you first need to upgrade to the latest version of
> git-review, by running "pip install -U git-review". Then you need to create
> a configuration file: either /etc/git-review/git-review.conf (system-wide)
> or ~/.config/git-review/git-review.conf (user-specific).
>
> The file should contain these two lines:
>
> [gerrit]
> defaultremote = origin
>
> Once you've made the change, any new Gerrit repos you clone using an
> authenticated URI will just work.
>
> You'll need to perform an additional step to migrate existing repositories.
> In each repository, run the following commands:
>
>   git remote set-url origin $(git config --get remote.gerrit.url)
>   git remote rm gerrit
>   git review -s
>
> Hope you find this useful.
> ___
> 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] OAuth and Identities

[Merlijn van Deen]

Hi Chris,

On 22 October 2013 05:45, Chris Steipp  wrote:

> OAuth does not support this, since the results of an api call
> using OAuth signatures aren't signed (only the request from the OAuth
> consumer is signed), so it's possible that an attacker could forge a
> response back to the application, and the application would think a
> different user was logged in. This is less likely if you're using https for
> your api calls, but it's surprisingly hard to get https right [1], even if
> you trust all your CA's.
>
(...)

>
> This is a common issue is being addressed by the OpenID Connect extension
> to OAuth2, which allows the application to request information about the
> person doing the authorization, and the result is signed by the server to
> prevent tampering.

(...)

I'm a bit confused by this -- I was under the impression https would be
enough to confirm I'm actually talking to the WMF's servers. The main
argument in [1] against just using https seems to be it's easy to ignore
invalid certificates. Is there another reason why it's dangerous to assume
you're talking to mw.o if the certificates check out?

Basically, I'm not quite sure whether using OIDC will help alleviate this
problem - you get a response back, but you still have to check the
signature! And with the ease of not checking the signature, you're
basically back to the same problem with not checking the ssl certificate.

Nonetheless, I think it's useful to add an authentication mechanism that
follows a standard - which is clearly not the case with the current
'api.php?meta=userinfo' calls.

Merlijn

[1]
http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l