Re: [Distutils] Google Auth is broken for PyPI

[Donald Stufft]

> On Feb 15, 2015, at 5:25 PM, Robert Collins  wrote:
> 
> I probably shouldn't, but I feel compelled to reply :).
> 
> On 11 February 2015 at 06:33, Donald Stufft  wrote:
>> 
>>> On Feb 10, 2015, at 11:23 AM, Martin v. Löwis  wrote:
>>> 
>>> Am 10.02.15 um 15:36 schrieb Donald Stufft:
 Honestly, I’d rather have less federated login not more. I wish the 
 current OpenID support had never been added.
 
>>> 
>>> Can you please elaborate on that position? Why is it useful to have
>>> separate accounts on separate systems?
>> 
>> Sure.
>> 
>> So the basic premise behind federated auth is that you can get a single set
>> of credentials on all (or most) of your sites and eliminate the need to have 
>> a
>> password for each site you visit.
>> 
>> My opinion is basically influenced by a number of factors:
>> 
>> 1. I feel like the goal of federated auth has failed in general and is 
>> unlikely
>>   to ever succeed. As a user of websites I have over 400 different entries in
>>   my password manager, even if 50% of them implement federated auth (which I
>>   feel like is a high number but that's not backed by math, just gut feeling)
>>   that's still over 200 entries I need to maintain in my password manager. In
>>   this case federated auth has not meaningfully reduced the burden of
>>   maintaining password for me since maintaining 200 isn't any easier than 400
>>   and instead it just complicates my login flow
> 
> So, what is success here? I'd call 200 less passwords to maintain and
> rotate on a regular basis a GOOD THING. I very much doubt that you
> would have 2FA set up on the other 200 things, so that would mean a
> change from 400 sites w only a couple having 2FA to 200 with regular
> rotations and 2FA, and 200 liabilities.

Success (for me) is when federated auth enables me to no longer need to worry
about passwords in my day to day use of the web. Currently it's not even close
and it doesn't appear to be getting any closer. The places where it is even
possible it's generally only possible to sign in with Github/Twitter/Facebook
and I'm unwilling to place the ability to authenticate as me to a wide number
of services with them. The only time I'm willing to do so is "throw away" sites
where my account on those sites don't really matter to me.


> 
>> 2. As a site operator I feel like authentication is a core part of the
>>   experience of using my site and by allowing federated auth on my site I'm
>>   giving up control over that user flow. A relevant example from PyPI is that
>>   a number of users signed up using MyOpenID which is no longer being
>>   maintained. This means that either PyPI has to tell those people
>>   "tough shit" or PyPI needs to figure out a mitigation tactic against that.
>>   Another example is that launchpad randomly starts failing for people, and
>>   it'll fail consistently for the same person until it just stops failing for
>>   them. I'm unable to actually reproduce this error so it's extremely hard
>>   for me to do anything else but shrug and tell them not to use it.
> 
> I'm genuinely curious here. Why do you feel that authentication is a
> core part of the experience? Its a necessary part, sure. But I find it
> hard to imagine that many people say 'that bug tracking site, its got
> *awesome authentication*'! I see authentication as something that is
> very very hard to get right, and incredibly easy to get wrong. I don't
> trust folk that are experts in e.g. bugtracking. Or code hosting. Or
> todo list management to necessarily understand all the intricacies of
> password handling (e.g. *how many sites don't use PBKDF2*!) Or worse
> truncate the input password you give to 8 characters (yes, seriously).
> Its not that the site operators aren't trustworthy in general, its
> that password handling is nasty:
> - its hard to get right
> - you won't know if you got it wrong until you or your users are compromised
> - even sites with dedicated teams doing just the IdP aspect get it wrong
> 
> I consider it irresponsible for less well resources sites to get into
> credentials management unless they truely have no choice: they're
> tackling something they're almost certain to get wrong.

Authentication is like a lot of pieces of maintaining a service, where if you
get it done *really well* people won’t notice it exists and if you do it wrong
people will notice it’s bad immediately. Sites go out of their way to take
control of the authentication flow to ensure that it gives the best possible
experience for their users. Delegating that out to someone else is giving up
control of it, which means that if the place it's been delegated to isn't able
to keep up then you're SOL because you've exposed what should be implementation
details of a particular app to the end user.

You say that you don't trust them to get authentication correct, which seems
silly to me given that you apparently trust them to handle ACLs or any number
of other parts of a secure web app correctly. Ho

Re: [Distutils] Google Auth is broken for PyPI

[Robert Collins]

I probably shouldn't, but I feel compelled to reply :).

On 11 February 2015 at 06:33, Donald Stufft  wrote:
>
>> On Feb 10, 2015, at 11:23 AM, Martin v. Löwis  wrote:
>>
>> Am 10.02.15 um 15:36 schrieb Donald Stufft:
>>> Honestly, I’d rather have less federated login not more. I wish the current 
>>> OpenID support had never been added.
>>>
>>
>> Can you please elaborate on that position? Why is it useful to have
>> separate accounts on separate systems?
>
> Sure.
>
> So the basic premise behind federated auth is that you can get a single set
> of credentials on all (or most) of your sites and eliminate the need to have a
> password for each site you visit.
>
> My opinion is basically influenced by a number of factors:
>
> 1. I feel like the goal of federated auth has failed in general and is 
> unlikely
>to ever succeed. As a user of websites I have over 400 different entries in
>my password manager, even if 50% of them implement federated auth (which I
>feel like is a high number but that's not backed by math, just gut feeling)
>that's still over 200 entries I need to maintain in my password manager. In
>this case federated auth has not meaningfully reduced the burden of
>maintaining password for me since maintaining 200 isn't any easier than 400
>and instead it just complicates my login flow

So, what is success here? I'd call 200 less passwords to maintain and
rotate on a regular basis a GOOD THING. I very much doubt that you
would have 2FA set up on the other 200 things, so that would mean a
change from 400 sites w only a couple having 2FA to 200 with regular
rotations and 2FA, and 200 liabilities.

> 2. As a site operator I feel like authentication is a core part of the
>experience of using my site and by allowing federated auth on my site I'm
>giving up control over that user flow. A relevant example from PyPI is that
>a number of users signed up using MyOpenID which is no longer being
>maintained. This means that either PyPI has to tell those people
>"tough shit" or PyPI needs to figure out a mitigation tactic against that.
>Another example is that launchpad randomly starts failing for people, and
>it'll fail consistently for the same person until it just stops failing for
>them. I'm unable to actually reproduce this error so it's extremely hard
>for me to do anything else but shrug and tell them not to use it.

I'm genuinely curious here. Why do you feel that authentication is a
core part of the experience? Its a necessary part, sure. But I find it
hard to imagine that many people say 'that bug tracking site, its got
*awesome authentication*'! I see authentication as something that is
very very hard to get right, and incredibly easy to get wrong. I don't
trust folk that are experts in e.g. bugtracking. Or code hosting. Or
todo list management to necessarily understand all the intricacies of
password handling (e.g. *how many sites don't use PBKDF2*!) Or worse
truncate the input password you give to 8 characters (yes, seriously).
Its not that the site operators aren't trustworthy in general, its
that password handling is nasty:
 - its hard to get right
 - you won't know if you got it wrong until you or your users are compromised
 - even sites with dedicated teams doing just the IdP aspect get it wrong

I consider it irresponsible for less well resources sites to get into
credentials management unless they truely have no choice: they're
tackling something they're almost certain to get wrong.

> 3. I feel like unless you solely rely on federated auth, then federated auth 
> is
>always going to be a second class citizen for any particular website. For
>instance Travis CI uses federated auth via Github only, but that's the only
>thing they support for authentication so everything works well with that. 
> On
>the other hand a number of sites support federated auth ontop of local
>accounts and federated auth is almost always worse in some ways, sometimes
>as simple as the username you get is kinda crappy (dstufft_)
>sometimes some features don't work (or don't work very well) at all like
>on PyPI where we need to authenticate people outside of a web context so
>if we don't have usernames/passwords then we end up needing to require the
>user to register a secondary "api password" or API key.

Relying solely on federated auth is fine by me :). You don't need to
tie yourself to one provider. Yes, most users will use just one of
fb/github/google/lp/twitter in our community, but you can (and should)
do unification on email address's to allow dealing with failed
providers [but only for trustworthy providers or by doing an email
verification step before unifying] and manage ACLs and privileged
operations locally.

The fact that some sites doit crappily is in no way an inditement of
the basic tech - in fact some sites do it really well. Its gotten so
good that these days the only time I will sign into a site t

Re: [Distutils] Google Auth is broken for PyPI

[Nick Coghlan]

On 11 February 2015 at 04:28, Jeremy Stanley  wrote:
> On 2015-02-10 12:33:29 -0500 (-0500), Donald Stufft wrote:
> [...]
>> In a slightly hypocritical view point, I actually think that at
>> some point we should get something like id.python.org which is an
>> IdP and switch all of the *.python.org sites to authenticate
>> against that instead of keeping local user accounts. This would
>> reduce the number of passwords that Python inflicts on people but
>> it still keeps authentication within our (PSF/Python/whatever)'s
>> control. This is more along the lines of implementing SSO using a
>> federated auth technology than actual federated auth though.
>
> The OpenStack community is in the process of doing this already (for
> exactly all of the same reasons you stated), so I'm happy to discuss
> details or point you to relevant ML/IRC conversations and software
> if it helps in any way.

Likewise, although in my case, Fedora had the Fedora Account System in
place long before I got involved in the project, and in my experience
it works well :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Nick Coghlan]

On 11 February 2015 at 03:33, Donald Stufft  wrote:
>
> In a slightly hypocritical view point, I actually think that at some point we
> should get something like id.python.org which is an IdP and switch all of the
> *.python.org sites to authenticate against that instead of keeping local
> user accounts. This would reduce the number of passwords that Python inflicts
> on people but it still keeps authentication within our (PSF/Python/whatever)'s
> control. This is more along the lines of implementing SSO using a federated
> auth technology than actual federated auth though.

This is the approach that Fedora uses [1], and it offers a lot of
benefits in making it possible to implement infrastructure services as
independently updated components, while using role-based access
control for authorisation management. One of the key practical
benefits is providing a single place for people to register their
public SSH keys, while one of the key community building benefits is
that reliably federating identity across the various Fedora
infrastructure services enables the badge system that allows people to
more easily be appropriately credited for their contributions to the
project. If you start doing 2FA, then the identity management server
becomes the place where you do your token management.

If we keep the focus specifically on PyPI, then the benefits of
breaking out a separate identity service mostly amount to making it a
bit easier to introduce a build service in the future (since PyPI and
the build service would be peers using a common identity provider,
making it easier to accommodate things like alternate experimental
PyPI front ends or separating the upload service from the publishing
service).

Things start to get a bit more interesting once we consider a world
where mail.python.org has been upgraded to Mailman 3, and we actually
have the concept of a "user profile" for the mailing list
infrastructure (as part of the HyperKitty archiver/web gateway). In
that case, then having HyperKitty/Mailman 3/PyPI sharing an identity
provider would make it feasible to let user's opt in to listing their
PyPI packages on their mail.python.org profile, which may provide
useful context in some discussions.

And then once we expand our sphere of consideration even further into
CPython core development, then I think core developers would gain the
most in the near term, as we touch almost all the major identity silos
(hg.python.org, pypi.python.org, buildbot.python.org, bugs.python.org,
wiki.python.org) regularly, with the release managers also needing to
deal with www.python.org. It's also worth noting that both of the
current workflow improvement proposals suggest adding yet another
identity silo in the form of a forge.python.org service.

Longer term, the shared identity model does offer a benefit in terms
of reducing barriers to entry: it means that anyone that has created
an account on PyPI to distribute software, or on Mailman 3 to
subscribe to a mailing list, will already have an account that lets
them file bugs on bugs.python.org or submit pull requests on the
future forge.python.org.

Another aspect to consider is that once you decide to have a single
authoritative identity provider *within* the ecosystem, it's also
possible to adopt models like the one Stack Overflow uses, where you
can *link* other profiles to your account and use them to login once
you do, but you're still required to be able to authenticate directly
with a password (If I recall correctly, DISQUS uses a similar setup,
although I think the "native" password controlled account is optional
there). So this approach isn't necessarily about "no social auth
allowed" - it's about managing the risk of what happens if an external
identity provider goes away at some point in the future.

Cheers,
Nick.

[1] https://admin.fedoraproject.org/accounts/

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Ian Cordasco]

On Tue, Feb 10, 2015 at 1:56 PM, Barry Warsaw  wrote:
> On Feb 10, 2015, at 07:06 PM, Martin v. Löwis wrote:
>
>>I think this is your personal usage primarily. A lot of user just avoid
>>having to use a password manager, and use the same password on many
>>systems. (Of course, many people also *do* use different passwords, and
>>some also use passwords managers)
>
> Actually, I wouldn't be surprised if most users just use the password manager
> built into their browser.
>
> Cheers,
> -Barry
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>

Which password manager is that? lynx doesn't have a password manager!
I want this new fancy feature too!
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Barry Warsaw]

On Feb 10, 2015, at 07:06 PM, Martin v. Löwis wrote:

>I think this is your personal usage primarily. A lot of user just avoid
>having to use a password manager, and use the same password on many
>systems. (Of course, many people also *do* use different passwords, and
>some also use passwords managers)

Actually, I wouldn't be surprised if most users just use the password manager
built into their browser.

Cheers,
-Barry


pgpit8aDpfp7D.pgp
Description: OpenPGP digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Donald Stufft]

> On Feb 10, 2015, at 1:06 PM, Martin v. Löwis  wrote:
> 
> Am 10.02.15 um 18:33 schrieb Donald Stufft:
>>> Can you please elaborate on that position? Why is it useful to have
>>> separate accounts on separate systems?
>> 
>> Sure.
> 
> Thanks! Just one comment - without the desire to get into a long-winded
> discussion.
> 
>> 1. I feel like the goal of federated auth has failed in general and is 
>> unlikely
>>   to ever succeed. As a user of websites I have over 400 different entries in
>>   my password manager, even if 50% of them implement federated auth (which I
>>   feel like is a high number but that's not backed by math, just gut feeling)
>>   that's still over 200 entries I need to maintain in my password manager. In
>>   this case federated auth has not meaningfully reduced the burden of
>>   maintaining password for me since maintaining 200 isn't any easier than 400
>>   and instead it just complicates my login flow 
> 
> I think this is your personal usage primarily. A lot of user just avoid
> having to use a password manager, and use the same password on many
> systems. (Of course, many people also *do* use different passwords, and
> some also use passwords managers)

Sure! Lots of people do absolutely just re-use passwords. Though I don’t think
many of those same users are likely to be (knowingly at least) using OpenID.
They’re more likely to use the “Sign in With X” buttons where X is something
like Google, Facebook, Twitter, etc. Which I dislike (except in cases where
you need to optimize for low impact user accounts like blog comments) because
they are an explicit relationship with another entity without any power to
influence what they do with the trust you grant them by letting them control
log ins to your site.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Jeremy Stanley]

On 2015-02-10 12:33:29 -0500 (-0500), Donald Stufft wrote:
[...]
> In a slightly hypocritical view point, I actually think that at
> some point we should get something like id.python.org which is an
> IdP and switch all of the *.python.org sites to authenticate
> against that instead of keeping local user accounts. This would
> reduce the number of passwords that Python inflicts on people but
> it still keeps authentication within our (PSF/Python/whatever)'s
> control. This is more along the lines of implementing SSO using a
> federated auth technology than actual federated auth though.

The OpenStack community is in the process of doing this already (for
exactly all of the same reasons you stated), so I'm happy to discuss
details or point you to relevant ML/IRC conversations and software
if it helps in any way.
-- 
Jeremy Stanley
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Martin v. Löwis]

Am 10.02.15 um 18:33 schrieb Donald Stufft:
>> Can you please elaborate on that position? Why is it useful to have
>> separate accounts on separate systems?
> 
> Sure.

Thanks! Just one comment - without the desire to get into a long-winded
discussion.

> 1. I feel like the goal of federated auth has failed in general and is 
> unlikely
>to ever succeed. As a user of websites I have over 400 different entries in
>my password manager, even if 50% of them implement federated auth (which I
>feel like is a high number but that's not backed by math, just gut feeling)
>that's still over 200 entries I need to maintain in my password manager. In
>this case federated auth has not meaningfully reduced the burden of
>maintaining password for me since maintaining 200 isn't any easier than 400
>and instead it just complicates my login flow 

I think this is your personal usage primarily. A lot of user just avoid
having to use a password manager, and use the same password on many
systems. (Of course, many people also *do* use different passwords, and
some also use passwords managers)

Regards,
Martin

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Ethan Furman]

On 02/10/2015 09:33 AM, Donald Stufft wrote:
> 
> In a slightly hypocritical view point, I actually think that at some point we
> should get something like id.python.org which is an IdP and switch all of the
> *.python.org sites to authenticate against that instead of keeping local
> user accounts.

I don't think this is hyprocritical at all, because --

> [...] it still keeps authentication within our (PSF/Python/whatever)'s
> control.

And implementing our own global login system is vastly different from relying 
on XYZ's authentication services.

And, yes, it would be nice to have (and, no, I'm not voluteering ;) .

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Donald Stufft]

> On Feb 10, 2015, at 11:23 AM, Martin v. Löwis  wrote:
> 
> Am 10.02.15 um 15:36 schrieb Donald Stufft:
>> Honestly, I’d rather have less federated login not more. I wish the current 
>> OpenID support had never been added.
>> 
> 
> Can you please elaborate on that position? Why is it useful to have
> separate accounts on separate systems?

Sure.

So the basic premise behind federated auth is that you can get a single set
of credentials on all (or most) of your sites and eliminate the need to have a
password for each site you visit.

My opinion is basically influenced by a number of factors:

1. I feel like the goal of federated auth has failed in general and is unlikely
   to ever succeed. As a user of websites I have over 400 different entries in
   my password manager, even if 50% of them implement federated auth (which I
   feel like is a high number but that's not backed by math, just gut feeling)
   that's still over 200 entries I need to maintain in my password manager. In
   this case federated auth has not meaningfully reduced the burden of
   maintaining password for me since maintaining 200 isn't any easier than 400
   and instead it just complicates my login flow 

2. As a site operator I feel like authentication is a core part of the
   experience of using my site and by allowing federated auth on my site I'm
   giving up control over that user flow. A relevant example from PyPI is that
   a number of users signed up using MyOpenID which is no longer being
   maintained. This means that either PyPI has to tell those people
   "tough shit" or PyPI needs to figure out a mitigation tactic against that.
   Another example is that launchpad randomly starts failing for people, and
   it'll fail consistently for the same person until it just stops failing for
   them. I'm unable to actually reproduce this error so it's extremely hard
   for me to do anything else but shrug and tell them not to use it.

3. I feel like unless you solely rely on federated auth, then federated auth is
   always going to be a second class citizen for any particular website. For
   instance Travis CI uses federated auth via Github only, but that's the only
   thing they support for authentication so everything works well with that. On
   the other hand a number of sites support federated auth ontop of local
   accounts and federated auth is almost always worse in some ways, sometimes
   as simple as the username you get is kinda crappy (dstufft_)
   sometimes some features don't work (or don't work very well) at all like
   on PyPI where we need to authenticate people outside of a web context so 
   if we don't have usernames/passwords then we end up needing to require the
   user to register a secondary "api password" or API key.

4. I feel like none of the current solutions to federated auth are very good.
   OpenID relies on using an URL as your "personal identifier" which I feel
   like is a strange and foreign concept to most users. The way around this is
   often to just hardcode a list of sites, but then as a site operator you're
   implicitly recommending that users go sign up for one of those sites and
   use them on your site to login. This is creating an explicit relationship
   between your site and the other site, a relationship in which you often have
   no power (for instance, Google <-> PyPI, we're powerless to do anything
   about them deprecating OpenID other than just sucking it up and dealing with
   it). Persona did offer a way around this, but persona had other failings
   like relying on the domain that you happened to be using for your email to
   implement a persona IdP or otherwise falling back to an implicit relationship
   with the fallback provider, again one where you're more or less powerless to
   the operators of that service.


Overall I think that the use of federated auth, as a site operator, is really
only worth it over the loss of control in two scenarios:

A. When your site is already entwined with another site and relying on them for
   authentication is simply increasing that. An example of this from above is
   Travis CI where they only work with things hosted on GitHub so also relying
   on GitHub for authentication isn't that big of a deal and actually makes
   things better since they can then integrate with GitHub's permissions to
   check if you have commit on a particular repository.

B. When creating an account is likely to be enough of a burden to make people
   decide not to interact with your site. This category is basically completely
   comprised of sites that do not have long standing relationships with their
   users. The only real example I can think of this of the top of my head is
   sites with comments enabled like blogs, news sites, etc. The commentors are
   unlikely to have or want a long standing relationship with your site, they
   just want to make a quick one off comment and then possibly never come
   back. Sites like PyPI otherhand the cost of creating 

Re: [Distutils] Google Auth is broken for PyPI

[Martin v. Löwis]

Am 10.02.15 um 15:36 schrieb Donald Stufft:
> Honestly, I’d rather have less federated login not more. I wish the current 
> OpenID support had never been added.
>

Can you please elaborate on that position? Why is it useful to have
separate accounts on separate systems?

Regards,
Martin

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Barry Warsaw]

On Feb 10, 2015, at 02:27 PM, Brett Cannon wrote:

>Does Launchpad support OpenID Connect? If so then migrating to that would
>solve this.

No, I don't believe so.  I've just filed this bug:

https://bugs.launchpad.net/launchpad/+bug/1420348

>Otherwise it may be time to have a serious look at our federated login
>support and consider adding GitHub and Bitbucket for wider reach as OpenID
>1.0/2.0 is extremely niche at this point.

I'd prefer not to *remove* OpenID support if it's still working, which it is.
And while I think GH and BB support might be useful, it's important to
remember that those are both closed systems, so I would put them on par with
Google, Facebook, or Yahoo! SSO.

Launchpad at least has the advantage of being free software, so anyone with
sufficient motivation and resources could contribution the needed support.

Cheers,
-Barry


pgpdeArtpYBY9.pgp
Description: OpenPGP digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Donald Stufft]

> On Feb 10, 2015, at 9:27 AM, Brett Cannon  wrote:
> 
> 
> 
> On Mon Feb 09 2015 at 2:42:46 PM Barry Warsaw  > wrote:
> On Feb 08, 2015, at 11:37 PM, Richard Jones wrote:
> 
> >Google has discontinued support for OpenID, so we're not going to be
> >putting any effort into debugging this issue.
> 
> I hope you'll continue to support other OpenID providers, e.g. Launchpad.
> 
> Does Launchpad support OpenID Connect? If so then migrating to that would 
> solve this.
> 
> Otherwise it may be time to have a serious look at our federated login 
> support and consider adding GitHub and Bitbucket for wider reach as OpenID 
> 1.0/2.0 is extremely niche at this point. 

Honestly, I’d rather have less federated login not more. I wish the current 
OpenID support had never been added.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Brett Cannon]

On Mon Feb 09 2015 at 2:42:46 PM Barry Warsaw  wrote:

> On Feb 08, 2015, at 11:37 PM, Richard Jones wrote:
>
> >Google has discontinued support for OpenID, so we're not going to be
> >putting any effort into debugging this issue.
>
> I hope you'll continue to support other OpenID providers, e.g. Launchpad.
>

Does Launchpad support OpenID Connect? If so then migrating to that would
solve this.

Otherwise it may be time to have a serious look at our federated login
support and consider adding GitHub and Bitbucket for wider reach as OpenID
1.0/2.0 is extremely niche at this point.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Barry Warsaw]

On Feb 08, 2015, at 11:37 PM, Richard Jones wrote:

>Google has discontinued support for OpenID, so we're not going to be
>putting any effort into debugging this issue.

I hope you'll continue to support other OpenID providers, e.g. Launchpad.

Cheers,
-Barry



pgpVJAH8ZQaH8.pgp
Description: OpenPGP digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[John Wong]

What if we just remove that as an option?
> *Important:* Google has deprecated OpenID 2.0 and will shut it down after
a migration period. If your app uses OpenID 2.0, you must migrate your app
by the shutdown date April 20, 2015

But what happen to existing users who registered with OpenID? Is PyPI
planning to migrate to OAuth 2.0
 (and what
about warehouse?)

Thanks.

John

On Sun, Feb 8, 2015 at 6:37 PM, Richard Jones  wrote:

> Google has discontinued support for OpenID, so we're not going to be
> putting any effort into debugging this issue.
>
>
>  Richard
>
> On Sun Feb 08 2015 at 6:09:22 AM anatoly techtonik 
> wrote:
>
>> Hi,
>>
>> Attempt to authorize with Google gives "Something wen wrong" page
>> shown at https://pypi.python.org/pypi?:action=login&provider=Google
>>
>> Please, CC.
>> --
>> anatoly t.
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Randy Syring]

How about removing the Google icon from the UI so as to avoid confusion?

*Randy Syring*
Husband | Father | Redeemed Sinner

/"For what does it profit a man to gain the whole world
and forfeit his soul?" (Mark 8:36 ESV)/

On 02/08/2015 06:37 PM, Richard Jones wrote:
Google has discontinued support for OpenID, so we're not going to be 
putting any effort into debugging this issue.



 Richard

On Sun Feb 08 2015 at 6:09:22 AM anatoly techtonik 
mailto:techto...@gmail.com>> wrote:


Hi,

Attempt to authorize with Google gives "Something wen wrong" page
shown at https://pypi.python.org/pypi?:action=login&provider=Google

Please, CC.
--
anatoly t.
___
Distutils-SIG maillist  - Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Google Auth is broken for PyPI

[Richard Jones]

Google has discontinued support for OpenID, so we're not going to be
putting any effort into debugging this issue.


 Richard

On Sun Feb 08 2015 at 6:09:22 AM anatoly techtonik 
wrote:

> Hi,
>
> Attempt to authorize with Google gives "Something wen wrong" page
> shown at https://pypi.python.org/pypi?:action=login&provider=Google
>
> Please, CC.
> --
> anatoly t.
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig