[02:08] wgrant: to use the u1 account on the phone for auth to launchpad in an app [02:41] dobey: We're certainly never going to support validating tokens directly against SSO, but it may be acceptable to have a way to acquire a Launchpad one given an SSO one. [02:42] But then one must consider the security issues. SSO's OAuth model is very very broken. [02:45] SSO doesn't have an OAuth model [02:45] Mrh? [02:45] It does so. [02:46] it has a token similar to an oauth token, and it supports oauth signatures, but it is not oauth [02:46] * lifeless gets popcorn [02:46] http://canonical-identity-provider.readthedocs.org/en/latest/resources/token.html#oauth-token [02:46] OAuth token [02:46] An OAuth token represents a token used to sign requests using the OAuth 1.0a spec. [02:47] The token acquisition method is thoroughly non-standard, but that doesn't matter here. [02:47] yes, the token itself and the signing with hmac are the only parts of oauth that sso uses from oauth [02:47] Fundamentally, some random app on my phone that uses U1 for auth shouldn't also be able to log into LP as me. [02:47] SSO OAuth model today does not support that. [02:47] AIUI [02:48] why shouldn't it? if instead of an oauth token, the email/password were stored in the phone's keyring, an app could log into launchpad as you [02:48] Sure [02:49] And if someone did that, they would be reckless. [02:49] This is why apps using SSO OAuth tokens directly is perilous. [02:50] I actually only wanted to give the U1 app access to my U1 files, not root on every Ubuntu machine in the world. [02:50] is this a time to trot out that authentication != authorisation - of the agent with the token [02:50] That's the problem. [02:50] there is a big difference between u1 app access, and root on every machine in the world [02:51] In SSO authz == authn AFAIK. [02:51] the fact that it is a token is not sufficient to let it behave like you on every site that permits OAuth [02:51] dobey: Right, but one needed an SSO OAuth token to access U1, and if that same token could be used to authenticate to LP... [02:51] dobey: wgrant is arguing that if the same token from u1 app access can be given to LP to access LP's API, then for all the ubuntu core devs, it would be equivalent [02:52] dobey: note not 'token from same source', but specifically 'same token' [02:53] lifeless, wgrant: note that i never suggested removing the additional level of access control on oauth tokens that launchpad has [02:53] dobey: I'm not clear what you were proposing then [02:54] dobey: (or what problem you're solving) [02:55] lifeless: launchpad's oauth token acquisition is also not strictly oauth1.0a either. if i could use the same token, using sso to do the validation and launchpad to control access, it would make it easier to provide a nice UX i think [02:58] dobey: But that relies on SSO having token usage restrictions. [02:58] It does not today, so they cannot be acceptable for authentication to Launchpad. [02:59] wgrant: why? if launchpad keeps the token usage restriction it has now, on the lp side, sso itself doesn't need it, does it? [02:59] (Launchpad can restrict the tokens all it likes, except how do you authorise them in the first place unless the token defaults to having token authorisation permissions, trivially defeating everything) [03:00] To authorise a token you need to authenticate yourself to LP. The way to do that today is through OpenID via SSO. [03:00] SSO tokens are insufficiently secure to permit that, as unprivileged applications hold them. [03:01] well, then i wonder how hard it would be to get oauth2 implemented on lp [03:01] Precisely describe the nature of the problem you're trying to resolve. [03:02] writing an app that doesn't use the python library or gnome-keyring, but uses online-accounts [03:03] currently lp is oauth1.0a-but-not-quite, which makes it a bit more difficult than it should be [03:03] What's the not quite bit? [03:03] We're almost exactly OAuth 1.0a [03:03] Unlike SSO which has a totally different token acquisition dance. [03:03] yes, almost exactly is not exactly :) [03:04] I don't know of any material differences off-hand. [03:04] empty consumer bits [03:05] at least, the empty consumer bits was the issue i ran into last time i tried to make an online-accounts plug-in for lp [03:05] Rather than requiring explicit manual registration of each consumer, the consumer secret is always empty. [03:06] Given the consumer secret is usually hardcoded in the o-a plugin anyway, how does that complicate things? [03:10] oh, looking at 1.0a spec again, it says consumer secrete may be empty, and that is the empty thing on lp, so maybe just a bug in online-accounts for that [03:11] If you can find the problem, we can examine how to fix it. [03:11] But SSO OAuth can never be used directly (it makes reliability impossible), and can't be used to generate new LP tokens directly due to the security design. [03:12] anyway, i was just curious about sso as a means for majority of users to interact with bug reports and such. coredevs are obviously a special case [03:12] But core devs aren't a terribly special case. [03:12] I also don't want a bug in my phone's U1 app to be able to compromise $important_trunk_branch. [03:12] ther eis no u1 app [03:13] there is no u1 file sync or such any more [03:13] There was. [03:13] there is only u1 the accounts system [03:13] And there will probably be something similar again. [03:13] and the account has always been separate from the file sync [03:13] But the token has not been. [03:13] I remember SSO went down a few times because U1 started validating every request against it. [03:15] nevermind [03:22] Anyway, hopefully you can identify whatever it is that prevents o-a from working. === Daryl_ is now known as Guest86047 [07:02] Hello, do the personal +junk branches have an expiration set on them ? [07:05] ki7mt: No. They're just not associated with any particular project; they still stick around until you delete them. [07:05] wgrant, Ok, thanks. [07:11] wgrant, While Im here, I balled up when uploading a ppa, I added a package to the wrong PPA, now I have a PPA wiht two package, one correct and the other belongs to another PPA, how can I fix that? [07:13] ki7mt: On the PPA's page, click "View package details" then "Delete packages". [07:14] wgrant, :-) .. Yup I was just there, and added a Delete request. Should have looked better before asking. sri, been a long day. [07:14] :) === gcollura is now known as gcollura|brb === gcollura|brb is now known as gcollura [14:20] hi [14:20] I have a armhf build that says "9 hours ago (estimated) " [14:20] it's still building... is this normal? [14:20] https://code.launchpad.net/~libretro/+recipe/mame-libretro-daily [14:22] The estimate's probably just gratuitously wrong because of insufficient data. The build does appear to be making progress. [14:23] (As in, I've had the logtail change on reload) [14:24] Big compiles under qemu can be not the fastest things in the world ever. === charles_ is now known as charles [15:52] cjwatson: ping, if you're around. [15:53] if you're in vacation mode still i'll leave you be, though. [15:54] teward: I'm here [15:56] cjwatson: is there any way to confirm what you had said previously about non-alternate-arch PPAs being able to hold the alternate-arch packages? Asked ahead of my requesting ARM builds on the PPAs I'm thinking about getting those builds on, to determine whether I have to deal with alternate-arch enablement on the production PPAs in addition to the staging PPAs. [15:56] you had mentioned it should be easy to test... [15:57] well I already tested it [15:57] I mean not with copies between two PPAs but that doesn't make a difference here [15:57] you only need to enable restricted architectures on the PPAs where you actually plan to build stuff [15:58] ahhh, okay, awesome. thanks :) === gcollura_ is now known as gcollura === gcollura__ is now known as gcollura [21:06] Hi, is it possible to edit a comment I made on a bug report? [21:12] Dry_Lips: Not as such, but you can hide your own comment and post an improved version if you prefer. [21:13] well, it was just a minor issue, one additional word that I would like to add if there was an easy way to edit my comment... [21:18] I'm afraid not. https://bugs.launchpad.net/launchpad/+bug/80895 [21:18] Ubuntu bug 80895 in Launchpad itself "comments on bugs/answers/merge proposals/etc cannot be edited" [Low,Triaged] [21:18] It would be a reasonable thing to have, but it's not a priority for the (stretched) core team at the moment. [21:24] Yeah, that's something that I think many people would like to see implemented... [21:25] But I understand that the team might not have resources to do something about it