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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
