TrustingThirdPartyRepositories

Trusting Third Party Repositories

The Problem

Each Linux distribution maintains its own repository of packages it compiles, tests, and maintains for its users. Installing packages from these repositories is very easy for the users.

There are also independent software vendors (e.g. Wine, Adobe, Skype, and Google) who provide their own package repositories. These are not as easy to use because the end user has to configure their package manager to know about and trust each ISV's repository by hand. Here are a few examples of such repositories and the steps needed to use them:

It was difficult for me to gather that information, and it's even more difficult for users to find it and follow it. It's even difficult for the software vendors to maintain (skype seems to have abandoned their repositories?). There needs to be a better way.

Suse's Proposal: make web downloads easier

http://en.opensuse.org/Standards/One_Click_Install is Suse proposal for simplifying ISV download pages. With their idea, instead of the user clicking on the appropriate .deb or .rpm, they click on a .ymp (really a little xml file); their package manager parses the file and selects the appropriate package to download. This is already implemented in OpenSuse.

An intern at Google implmented an example handler for .ymp written as a small C program that links to the PackageKit library; see http://www.cs.ucr.edu/~dperkins/projects/pk-oci This could potentially be used by any distro that uses PackageKit, so they don't need to write their own .ymp handler.

Ubuntu/Canonical's Proposal: add whitelist of trusted repositories

Ubuntu is considering address the problem of establishing trust, i.e. getting the package repository's key or URL into the package manager. See:

In short, they propose to add a short list of third party repositories to Ubuntu's "Add/Remove Packages" tool. To qualify, the repositories must meet a number of criteria (e.g. they must be signed, reputable, popular, and unsuitable for merging with Ubuntu's main repository). apturl will be extended to allow installing third party packages securely via the web.

Their proposal is still being formulated, and will be discussed at UDS in the second week of December 2008, probably Monday Dec 8.

The exact time and date of the discussion will be given here when available.

You can ask or answer questions remotely during the meeting via irc://irc.linuxfoundation.org/#packaging

Issues

Here are some issues that need discussing (originally taken from the BOF agenda on their page, but since expanded). Please edit this to add your own comments (it's easy to register for an account, see the bar at the left).

Generality

Whatever solution is adopted should not get in the way of ISVs who want to support both deb and yum repositories, i.e. the RPM and Yum flavors of the solution to this problem should use similar conventions and mechanisms if possible, to reduce the burden on ISVs who need to support many distributions. The Suse proposal is a nice example of a general approach.

Upgrade Issues/Dependencies

Everybody is afraid of dependency hell. Adding new repositories could make it much worse. What are the possible failure modes / threats, and rules would need to be enforced to avoid them?

Package Name Clashes

If two different repositories have packages that are named foo, what would "aptitude install foo" do?

The LSB has a package naming convention which could be used as an example. In their scheme, package names start with lsb-, continue with either the ISV's FQDN or a "provider name" registered with LANANA, and end with a hyphen and the product's name, followed by the package type. For instance, lsb-sun-staroffice-writer-ia32.rpm would be allowed because 'sun' is registered as a provider name. Alternately the longer name lsb-sun.com-staroffice-writer-ia32.rpm could be used because 'sun.com' is Sun's FQDN.

Perhaps we could use the same scheme, but make the lsb- prefix optional.

File Overwrite Issues

If two different repositories have packages that try to install /usr/bin/foo, who wins? (Hint: Not the user.)

One possible scheme -- and the one foreseen by the FHS -- is to require all packages from a given ISV to install in a subdirectory of /opt named after the ISV. The /opt namespace would need some management (like LANANA? Or use the FQDN of the vendor, as Java does?) e.g. packages from Skype.com would install to /opt/skype (a la LANANA) or /opt/com.skype (a la Java)

This scheme would be enforced by the package manager or the distro somehow. Ideas:

  • repositories could be kicked out if they don't follow it
  • the package manager could refuse to install packages that don't follow it
  • some kind of runtime protection could be used to make violations impossible
  • a dialog could be presented to the user for packages that need more access

One form of runtime protection is user id separation. One could define a unique userid for each vendor, create /opt/$PROVIDER as the userid, and have the package manager setuid to that user before copying files or running pre/post install scripts. This would prevent file overwrites. However, this would also prevent installing menu items, documentation, or symlinks to the app. It remains to be seen if there are reasonable ways to allow those common tasks, e.g. provide a setuid wrapper around xdg-utils that validates and then performs the request.

Other links

Comments on this page

TrustingThirdPartyRepositories (last edited 2008-12-07 20:18:37 by DanKegel)