Overview

• Launchpad entry: https://blueprints.edge.launchpad.net/soyuz/+spec/private-archive-tokens

• Created: 2008-09-03 by JulianEdwards

• Contributors:

• Depends on: n/a

Overall Summary

Summary: Store and manage access tokens for private archives. These tokens will be stored in the database and published to disk during the normal publishing cycle. A UI will manage the tokens allowing archive owners to generate new ones and delete old ones.

Goal/Deliverables:

• Publisher changes to generate the .htaccess file
• Schema changes to store the tokens
• UI changes to add/delete tokens

We will know we have finished when private archive owners can manage 3rd party access to their archives with no intervention from LP admins.

Release Note

Rationale

It's currently very time-consuming for admins to set up the .htaccess file for private archives. It's also frustrating for end-users to have to wait for an admin to do it.

We also wish to drive adoption of Launchpad, such that users of PPAs will need to have a Launchpad account to receive their access tokens.

Use cases

• Terry runs a private PPA containing commercial Python-related software packages. He wishes to allow Michael, his beta partner, access to download the packages at any time. Terry visits his PPA page, follows a link to a page that controls user-access to the archive, selects Michael's Launchpad account and generates an access token with no expiry date. Terry does not directly see the token but the page shows that Michael has permission to access the archive.
• John is a user who wants to download some of Terry's software. He arranges payment with Terry who gives him access via a token that expires in 1 week. John navigates to his profile page and follows a link to another page that lists all his access tokens for archives that he has permission to see. He copies the sources.list entry (which is presented with the basic auth. access token embedded already) to his own machine and downloads the software using his normal package managing software.
• Monty runs a private PPA in which he wishes to distribute software to his team of employees. He sets up an access permission that authorises a whole team to access his archive. Each team member will then have a separate token available so that when Monty fires someone from his team, only that person's access token is removed and the rest of the team retains access.

Assumptions

• Passwords are secure in the database.

User Interface

The PPA will have a new linked page that is available to the archive's owner(s) only. It will list authorised Launchpad users who can access the archive. It will allow the PPA owner to add, remove and set expiry dates on access for each user/team.

Archive users will be able to see a private page that shows all their current archive access via a list of archives and their corresponding sources.list entries, the latter being presented with the basic auth. token necessary to access the archive.

At some point this will be integrated with Ubuntu so that clicking a link will install the sources.list entry.

Implementation

• Schema changes (1 day)
• Fix the publisher to generate a .htaccess based on the tokens in the database (3 days)
• Add the admin UI to manage the tokens (4 days)
• Add UI for the archive user to list access (3 days)

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Schema Changes

What Database changes are you proposing? Do you need a new index created? Proposing a new table? If so, what does it look like?

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any

• how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the rollout template.)

Unresolved issues

Limiting downloads while allowing unlimited updates

The current spec includes a token (in a sources.list entry... it'd be great to see an example of what this will look like). This token could be potentially copied and used by others. But with the current .htaccess solution, I'm not sure how this could be prevented while at the same time allowing users ongoing access to updates (security/bug fixes).

I'm wondering whether it might be worth the extra effort of proxying the archive urls so we can do more than htaccess? There's probably lots I'm missing... just let me know.

CategoryProposal