Launchpad Moving to Closed Source Auth

Soon there will be a new release of launchpad and along with some new feature and bug fixes will be the move to only using an OpenID provider for the authentication. (This incidentally is why ground control 1.5 is broken currently)

The new OpenID system points to https://login.launchpad.net/ and most people here will have seen this OpenID system before. The problem is that this part of launchpad is not open source, it was taken by Canonical’s ISD which deals with development for the system admins. Interestingly this code base became the Ubuntu Single Sign On system after a rewrite, the system that launchpad will probably move towards after this interation.

What is worrying about the closed source oversight is that there has already been a number of reports of vulnerabilities in this OpenID provider software and long delays in fixes being applied. Worse, I can find no rationale for the code of such a security sensitive part of the system being put into a situation where it can not benefit from many eyes, code peer review.

There is hope. I have learned that there is a plan that as the OpenID consumption of launchpad matures, we will be able to choose which OpenID provider to use and not be bound to either the closed launchpad or Ubuntu providers when logging into launchpad.

What are your thoughts?

8 Responses to “Launchpad Moving to Closed Source Auth”

  1. Mark Unwin says:

    I thought one of the selling points of OpenID is that you are free to choose your OpenID provider…

  2. Roshan says:

    So long as a website is an OpenID consumer that works. However, everyone wants to be a provider and no one wants to be a consumer. Such is life.

  3. Benjamin Wohlwend says:

    With one prominent exception: facebook is only consuming, not providing. Seems they don’t want to damage their own proprietary (and sucky) facebook connect authentication protocol…

  4. Jef Spaleta says:

    Can you point to authoritative sources for the vulnerability reports you mention with details?

    -jef

  5. Tim Penhey says:

    Can you tell me how the change broke GroundControl? I thought you were using the launchpadlib and the api?

  6. doctormo says:

    Sure, it uses the login to process the OAuth request and upload and download ssh public keys.

    There is a plan to make a desktop client which can manage launchpadlib connections from a desktop, but it’s proving hard to impliment with openid.

  7. A couple comments:

    1. It would be simpler (and better for us) if you never had to interact with the OpenID provider from an automated client, and did everything through the web service instead. Right now some developers are working to publish key management features through the web service. Will this solve your Ground Control problem?

    2. launchpadlib now has a framework for writing standalone client programs that take the user’s Launchpad credentials and authorize an OAuth token. I wrote a console program, but I don’t know anything about GUI programming, so that’s the only one I tried to write. A couple people have offered to contribute GUI versions, but no one has delivered so far.

    If you can do without scraping the OpenID interaction, it would be great if you’d use this framework as the basis for your GUI client. I could put it into launchpadlib and other developers could easily reuse it.

  8. […] authentication however, Ground Control is currently broken.┬áDoctorMo wrote about the problem┬áhere. To get a feel for what Ground Control does though, take a look at the […]