launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Thank you for revisiting this Leonard.

I agree that plain unsecured files on disk are not as robust or secure
as gnome-keyring.

Key takeaway: If Kees and the Ubuntu security team are ok with this,
great. Do it, and sorry for the interrupt I raised (though I think it
was worth raising).

I have a few minor things you might like to consider.

We support KDE via Kubuntu and many Ubuntu developers use it;
gnome-keyring seems rather specific; can we, as Sidnei suggests, use
an abstraction layer to provide the benefits [currently only
encryption?] to those environments too?

Your passion for 3rd party developers needs its awesome, but this
design seems to be aiming at an unsatisfactory place.

We *have* had credentials for key members of Ubuntu compromised in the
past (through them pasting a openid cookie IIRC) and that route
remains unaltered. The change that you're doing makes oauth roughly
the same as openid cookies.

My experience with software design is that when we aim low, we achieve
low. I may simply be missing roadmap documents but the bigger picture
seems to be missing (to me).

So I have a challenge for us and our authentication and access control stories:

Aim High.

Perhaps we should set a vision for what we'd like to achieve here:
Single sign on (web, casual apps, daemons like Ubuntu One), persistent
credentials (if the user wants - I would!), easy authorisation of new
apps (single clicky clicky dialog, in some trusted computing base),
timeouts (defaulting on for high privilege levels), powerful per-app
controls (like the openid prompt which says what is being disclosed),
and only one protocol needed (rather than two, managed separately but
with equivalent issues).

We can then look at the stack, at what needs doing, and work it up.

-Rob