launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

> 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

Attachment: signature.asc
Description: This is a digitally signed message part