= Activating Development from the Desktop =

'''As a ''' opportunistic Ubuntu developer<<BR>>
'''I want ''' to quickly get set up to upload packages and share branches<<BR>>
'''so that ''' make cool stuff for Ubuntu<<BR>>

Opportunistic development tools like Quickly need to be able to help people who are not already set up for Ubuntu development by giving them a Launchpad account to which they can push branches and upload packages. This means generating and uploading an SSH key, a GPG key, signing the code of conduct and creating a PPA.

== Rationale ==

Canonical wants to see people making cool new applications and delivering them as quickly as possible to Ubuntu desktop users. Launchpad is a fundamentally important part of that, since it's the mechanism by which developers share code with other developers and packages with their users.

This helps people who are not yet Launchpad users become Launchpad users in a very convenient way.

== Stakeholders ==

 * didrocks, 2010-07-01
 * rickspencer3, 2010-07-05

== Constraints and Requirements ==

=== Must ===

 * Provide a clean way for Ubuntu desktop clients to upload a GPG key
 * Provide a clean way for Ubuntu desktop clients to upload an SSH key
 * Provide a clean way of creating a PPA for a user, including signing the code of conduct if necessary

=== Must not ===

 * Introduce new vulnerabilities allowing applications to enable new authentication methods (e.g. SSH, GPG) without the knowledge of the user.

=== Security constraints ===

 * The implementation MUST use a separate permission for adding GPG & SSH keys
 * This new permission MUST be either time-limited or one-shot
 * This new permission MUST NOT be able to be granted without explicit consent from an end user. (i.e. It must not be possible to use GRANT_PERMISSIONS to grant WRITE_SECURITY_SENSITIVE).

== Subfeatures ==

''Other LaunchpadEnhancementProposal``s that form a part of this one.''

== Workflows ==

=== Set up a fresh user for Ubuntu development (happy case) ===

From a desktop client, like Quickly, a user with a brand new Launchpad account can be set up for a PPA:

 1. Quickly generates an SSH key pair
 1. Quickly registers the public SSH key against that user with Launchpad
 1. Launchpad pops up the OAuth dialog, confirming that the user allows this level of access
 1. The user indicates agreement (probably by clicking "Change anything")
 1. Launchpad registers that SSH key, then emails the user (see below)
 1. Quickly generates a GPG key pair if it cannot find one for the user
 1. Quickly registers the public GPG key against that user with Launchpad
 1. Launchpad registers that GPG key, then emails the user (see below)
 1. Quickly displays the code of conduct to the user and asks them whether they agree to it
 1. If they do, Quickly signs the code of conduct with the user's newly-made GPG key, then posts the signed code of conduct to Launchpad
 1. Launchpad registers that the user has signed the code of conduct and emails the user (see below)
 1. Quickly creates a PPA for the user over the Launchpad API
 1. Quickly displays to the user their PPA URL and details about their new GPG key and SSH key, and tells the user how they can push branches and upload to their PPA.

==== New SSH key email ====

{{{
Hello Didier Roche,

Launchpad has just added a new SSH key to your account:
  $SSH_KEY_DETAILS

This key was added by you using (the Launchpad web site|$APPLICATION_NAME).

If you did _not_ add this key, or it was added by mistake, remove it now by clicking:
  $SSH_KEY_REMOVAL_URL

Otherwise, you do not need to take any action.

Now that your key is registered, you can use it to:
 * push branches to Launchpad
 * upload packages via SFTP to archive.launchpad.net

For more information, see https://help.launchpad.net/SSHKey.

Love,
Launchpad
}}}

Salient points:
 * There is a one-click URL for undoing the registration
 * The user is told that no action is required if this was intended
 * The user is told how the key was registered, so they can better match it against their memory
 * A link is provided to get more information so that
   * they know what they can do now
   * if they don't know about SSH keys and their security implications, they have a way of finding out

== Success ==

 * When users are sent an email whenever an SSH key is added to their Launchpad account
 * When users are sent an email whenever a GPG key is added to their Launchpad account
 * When Quickly can create a PPA for a new Launchpad user

We will measure how well we've done by:
 * Seeing how many SSH keys, GPG keys and PPAs have been created by Quickly
 * Seeing how many users with Quickly-generated SSH keys push branches
 * Seeing how many users with Quickly-generated GPG keys upload packages to their PPA

== References ==

 * [[https://launchpad.net/bugs/568981|bug 568981]]
 * [[https://launchpad.net/bugs/568982|bug 568982]]
 * https://lists.launchpad.net/launchpad-dev/msg03647.html -- launchpad-dev thread about this
   * https://lists.launchpad.net/launchpad-dev/msg03758.html
   * https://lists.launchpad.net/launchpad-dev/msg03742.html

== Thoughts? ==

 * Perhaps we should simply disable the rule about signing the code of conduct before using PPAs

=== Security risk ===

GPG and SSH keys are used to authenticate users for specific services. There is a big risk with allowing applications other than the website create new channels of authentication. Specifically, an application can, once trusted, create as many SSH keys and GPG keys as it likes, and then send the private keys to a malicious person. This malicious person can then use those keys to assume the identity of their victims, at least wrt sending emails, pushing branches and uploading packages.

This risk can be mitigated in two ways:
 1. Inform users via a reliable channel whenever new authentication methods are added to their account, thus giving them the opportunity to revoke those methods or to investigate the threat.
 1. Provide a new level of access control to the webservice that allows applications to add new authentication methods. Users would have to specifically grant such privileges to an application that needs them.

These options are complementary, not exclusive.

If we are going to send such an email, we should send it to the oldest, most-trusted address.