Summary

Explore enabling "trusted third-party repositories" in Ubuntu to provide for better user experience and smoother interactions between Ubuntu and popular applications. Examples of possible trusted repositories could include: wine (wine.budgetdedicated.com), Canonical, Google, or anyone who demonstrated trustworthiness and was willing to abide by the determined criteria to qualify themselves and be "whitelisted" within Ubuntu so their applications would be more readily available to Ubuntu users by virtue of their efforts with Ubuntu and their trusted position.

Release Note

Easier application installation in Ubuntu. Popular applications like $foo are just one click away now while still providing the high standard of reliability and security that our users know and expect.

Rationale

There are various applications that we can not ship in the default repository but that are popular and useful for our users. This includes proprietary applications like picasa or applications that move very fast and have a certain risk of regression that make them less suitable for the "backports" component (like the wine development release). We should provide a way to make it easier for our users to install them in a reliable and secure way.

Use Cases

  1. Boby wants to use picasa to store his photo collection. He goes to the google picasa page and clicks on "install picasa on ubuntu now"
  2. Alice wants to play the latest window game "foobar" that works only with the latest development release of wine.

Design

The technical part of this specification is going to be implemented as part of "apturl" and is described at jaunty-apturl-add-repo that spec outlines what needs to be done to support adding new repositories in a secure way.

This specification describes what repositories guidelines repositories must follow to be part of the whitelist. Potential repositories are: Adobe, Mozilla, Skype, WineHQ, etc.

In order to ensure quality and work with the community we should request that at least one commiter to the repository is MOTU (or core-dev). It should be encouraged to use backports when possible for fast moving free software projects. We should also try to ensure that the number of repositories does not grow out of bounds and that we keep a eye on them to ensure the quality stay high.

The policy will center on the following:

  1. what packages should be in a third party repository
  2. what process to follow to apply for getting whitelisted
  3. what guidelines to follow when new packages get added
  4. what guidelines to follow when packages get updated, especially on stable releases
  5. what namespace for the packages to use (both packagename and file system)
  6. guidelines for bug reporting
  7. what quality and QA process expectations for third party repositories

Implementation

The implementation will be done in the following steps:

  1. draft policy is posted to the ubuntu-devel mailinglist for discussion
  2. based on this input the policy will be refined (and possible re-posted)
  3. when the policy looks ready its sent to the technical board for approval

The final policy will be publish and a new team in Ubuntu will check whitelisted repositories regularly to ensure that its followed.

BoF agenda and discussion

Biggest concerns for us:

Security (no gate for malware/spyware), Quality (interaction with the official packages, upgradeability) Clear policy for how one gets in (no appearance of favoritism) (ScottK) Need to make it clear what is not Ubuntu - Appearance that external repos are part of Ubuntu causes problems with perception of quality, responsiveness, etc. (ScottK)

Things to talk about:

security

QA

compatibility

content

What content is suitable for such repositories. Requirements could be:

disable/remove repositories/packages

Discuss and identify when and how to

decision making

We need a team that does the reviews and has the power to add and remove repos.

Provide a lintian like tool that inspects the third party packages

Ideally we could have a package that puts just about all its files into /opt/vendor and then we handle what to do (eg instead of having the package install a .desktop file directly into /usr/share/applications they would drop it into /opt/vendor and then our system would look at it, make sure it was ok, and then move it. - limitation to the above: /opt/$foo ends up added to the path in one sense or another, so we have possibilities of namespace collisions that are not filesystem-level collisions, which makes conflicts /harder/ to detect...

Use cases

Two main use cases:

Launchpad integration

Jaunty+1,2:


CategorySpec

FoundationsTeam/Specs/JauntyTrustedThirdParties (last edited 2009-02-02 14:56:40 by cjwatson)