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 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 thoughts on “Launchpad Moving to Closed Source Auth

  1. 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.

  2. 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…

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


  4. 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.

  5. 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.

Comments are closed.