SoyuzPrivateArchiveTokens

Not logged in - Log In / Register

Contents

Overview

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:

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

Assumptions

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

Implementation

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 links a token with a subscriber. ArchiveSubscriber enumerates the people who have subscriptions to the archive.

Migration

Include:

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:

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:

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

SoyuzPrivateArchiveTokens (last edited 2009-01-28 14:18:40 by michael.nelson)