python OAuth in karmic

[James Westby]

Hi,

I would like some input on the issue of python OAuth code in karmic.

OAuth is gaining traction, and is used by Canonical in a few places,
notably here Launchpad and Ubuntu One.

Both of these projects have code in Ubuntu that does client-side OAuth,
both currently using the python-oauth module hosted on Google Code.
In Jaunty launchpadlib shipped an embedded copy of this code, and for
karmic I packaged it separately and uploaded a newer launchpadlib that
no longer embeds the code. ubuntuone-storage-protocol also currently
uses the same code, and currently ships an embedded copy of the code.

The module contains both server-side and client-side code, but only
the client-side part is used by any package in Ubuntu currently.

The OAuth specification was found to have a serious flaw which allows
a session fixation attack, and so a revision of the specification was
released, 1.0a, that mitigates this. This requires protocol changes,
but in terms of implementation only requires the library to change
the server-side code significantly.

Rodney and others tried to contribute changes to the python-oauth
codebase to allow 1.0a compliant servers to be implemented with it,
but the changes were slow to be accepted, and Rodney feels that
a complete solution has not yet been applied.

We currently have this code in main (with the partial fix), as it
was previously in main embedded in launchpadlib, but this is not
very satisfactory. Even worse is that ubuntuone embeds a copy of
this security-sensitive code which it is quite possible will have
to be modified again in order to fix other vulnerabilities.

It would be easy to change the package of ubuntuone-storage-protocol
to use the sytem code, but Rodney has expressed concern about me
doing this, as he it would require changes in other (not in Ubuntu)
parts of Ubuntu One. He also has concerns about the responsiveness
of the python-oauth upstream.

He has started a fork of python-oauth (poauth) on Launchpad, and
has talked with some Launchpad developers and I about switching to
it, but that has some drawbacks of its own.

I would therefore like some input from the release team on what
they feel would be the best course of action at this point for
Karmic and beyond. I see two possibilities:

  1) Change the packaging of ubuntuone-storage-protocol to
     use the system python-oauth, and do what we can to get any
     problems with that copy fixed. Leave the Ubuntu One team
     to deal with the fallout from this in their private code.

  2) Use Rodney's fork, and switch Ubuntu One and launchpadlib
     to use it. (The API should be the same for their uses).

I think the drawbacks of 2 are the point in the release cycle,
the usual issues with forking, plus concerns about being the
only ones to ship a security-sensitive piece of code that has
just been written and is likely to have issues of its own.

Thanks,

James