> However, for maverick, we need to go further and help the user to create > and get his full environment, which means: > - uploading his gpg key (for uploading his package) if he doesn't have > one > - upload his ssh key (for bzr) > - creating one ppa if he hasn't one > -> this imply make him sign the Code Of Conduct in a simple way.
There's no reason these functions can't be published through the web service (except of course lack of person-hours). But, it might be dangerous to publish 'upload GPG key' and 'upload SSH key'. For instance, allowing a web service client to upload a new GPG key could allow a malicious client to create its own GPG key, upload it as yours, and then upload packages 'signed' by you. In a sense this problem already exists--a malicious client can currently post atrocious comments in your name, etc. But this is more worrisome because 1) anything to do with GPG or SSH triggers one's security Spidey-sense, 2) a malicious app that uploads packages in your name can infect other peoples' computers. If we were to implement these features today, they would be available to clients that were granted the OAuth access level WRITE_PRIVATE or WRITE_PUBLIC. But almost every nontrivial web service client needs to write the dataset, which means it needs WRITE_PRIVATE or WRITE_PUBLIC. That leaves quite a lot of scope for abuse. But let's say we create a new level of access WRITE_SECURITY_SENSITIVE. Clients with WRITE_PRIVATE can do everything they can do now, but they can't do especially sensitive things like upload SSH keys. Clients with WRITE_SECURITY_SENSITIVE can do everything a WRITE_PRIVATE client can do, and can also upload SSH keys. A client like Quickly would need to ask for, and be granted, WRITE_SECURITY_SENSITIVE to function properly. If there are any existing activities protected with WRITE_PRIVATE clients, that we want to protect with WRITE_SECURITY_SENSITIVE instead, we could do that, at the cost of breaking existing clients until the end-user granted them the new permission. We can't prevent malicious clients from existing, but we can reduce the amount of trust the end-user needs to put in any particular client. If you grant WRITE_PUBLIC or WRITE_PRIVATE to most of your apps, and only grant WRITE_SECURITY_SENSITIVE to Quickly, then at least you can rest assured that your other apps aren't going to upload fake GPG keys to your account. You only have to worry about whether Quickly is well-audited. Leonard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
