• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

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 authorizes 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.
• HTTPS is well supported by apt and safe enough for shipping packages.

User Interface

The PPA will have a new linked page that is available to the archive's owner(s) only. It will list authorized 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.

Example of /etc/apt/sources.list.d/cprov_repo

deb https://<user>:<token>@private-ppa.launchpad.net/cprov/ubuntu intrepid main
deb-src https://<user>:<token>@private-ppa.launchpad.net/cprov/ubuntu intrepid main

For detailed UI stories, see UI Stories for Archive subscriptions

Lifecycle of a token

• an admin subscribes the individual / team and possibly puts an expiry date on there
  • the user / team is notified that they have been subscribed and told where to get the source.list entry
  • the individual goes to that page, presses "generate token" or "regenerate token" if they already have one
  • we generate the token and display the appropriate sources.list entry
• later, someone comes along and cancels that team's subscription
  • the team gets notified
  • some cron process notices that the relevant tokens are no longer valid and marks them so
  • that process then writes out an .htaccess file without those username/token combinations
• we have history of all of that

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

Schema changes are already landed with 2 new tables:

• ArchiveAuthToken, with columns id, archive, person, date_created, date_deactivated, token

• ArchiveSubscriber, with columns id, archive, registrant, date_created, subscriber, date_expires, status, description, date_cancelled, cancelled_by

ArchiveAuthToken links a token with a subscriber. ArchiveSubscriber enumerates the people who have subscriptions to the archive.

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/sources.list entry could be potentially copied and given to be used by others. Two potential solutions (assuming that access is controlled via .htaccess), are below.

AFAICS it doesn't make sense to automatically revoke the subscription after allowing time to download the software (by revoking the Archive Subscriber record, which would effectively deactivate the token), because the user is still a subscriber after they have downloaded the software (you might want to provide ongoing security/bug-fix updates to a subscriber, for example).

It might make sense to include an expiry-date for the Archive Auth Token itself, so that from when a subscriber generates a token, the token can be used for a certain time (enough to download the software), but this would require more than just a date_deactivated field on the Archive Auth Token (AFAICS, date_deactivated is just a reflection of the Archive Subscribers revocation or membership expiry). If, later on (say in two months time), an update becomes available for the software (bug/security-fix), there are two options that I can see:

1. The subscriber is notified via email (as the token in their sources.list will no longer enable apt-get to see that an update is available? (I don't know enough about apt-get yet to know if this is the case)) with a link to generate a new key for their LP user, providing them with a new sources.list entry (with the new token), with which they replace the old one (Cons: what a pain! Pros: secure with a new token generated by the user).
2. The subscriber's old expired token (that is already in their sources.list entry) is given a new expiry date. apt-get on users machine will automatically then see that an update is available (Pros: easy for user, Cons: user may miss the window of opportunity, little less secure as expired token is re-activated).

Archive URL proxying - worth the extra effort/complexity ?

I'm wondering whether it might be worth eventually proxying the archive urls so we can do more than htaccess? By proxying the archive urls we would be able to:

• keep stats on access (related to tokens) with ease (the Archive Auth Token would itself simply have fields for num_downloaded etc.).
• give tokens both an expiry as well as a number of available downloads (From what I've read, I understood that the tokens are always to be for a single user, but I'm not sure how this would work for volume licensing. Say a company with 80 employees wants to install Terry's software on all their machines, it would be useful to purchase a token that can be used for 100 downloads/updates at a time, to avoid the admin nightmare of getting every employee to create an LP account, then putting them in the right team etc.).

Please let me know where I've misunderstood things!

Controlling access not re-distribution and use of packages

It's important to realize that this implementation only deal with controlling access to the Launchpad hosted repository. We don't address issues like:

• Once a user has access to the repository (even if it's a minute or a single download) he will be able to use and re-distribute the original packages (from /var/lib/apt/cache) or even the reassembly the files installed in his disk, as he wishes. The only restriction would be the licenses involved.

There was a discussion about this in the Nexus sprint in Lexington and there are use-cases requiring restriction of access, installation and use of specific packages.

If ArchiveTokens were available externally (not only internally for .htaccess generation or proxying), let's say via LP-API; that information could be used in the targeted platform for restricting installation and use of the shipped binaries.

Okay, I deserve crucification for all this evilness ...

CategoryProposal