Launchpad Entry: partner-repositories
Created: MichaelVogt
Contributors: AlexanderSack
Packages affected: apturl, app-install-data
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
- 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"
- 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:
- what packages should be in a third party repository
- what process to follow to apply for getting whitelisted
- what guidelines to follow when new packages get added
- what guidelines to follow when packages get updated, especially on stable releases
- what namespace for the packages to use (both packagename and file system)
- guidelines for bug reporting
- what quality and QA process expectations for third party repositories
Implementation
The implementation will be done in the following steps:
- draft policy is posted to the ubuntu-devel mailinglist for discussion
- based on this input the policy will be refined (and possible re-posted)
- 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
- repos must be signed
- software must pass basic security audit
QA
- there must be a launchpad project page that users can report bugs against
- repo maintainer has to show activity in bugs
- packages must get (public?) testing before they are published on a stable release
- regular quality reviews by ubuntu developers.
compatibility
- problem of package name clashes (enforce in policy to not clash?)
- file overwrite issues
- upgrade issues/dependencies
content
What content is suitable for such repositories. Requirements could be:
- good and plausible reasons why packages cannot be maintained in ubuntu/debian
- licensing
- SRU policy
- is there a high-enough demand for the packages in repo to justify regular work by ubuntu developers imposed by requirement enforcements (e.g. QA reviews)?
- does it cover use-cases not yet addressed by software in ubuntu or software that might be suitable for ubuntu distribution?
disable/remove repositories/packages
Discuss and identify when and how to
- drop repos from whitelist for current ubuntu development release (e.g. next release)
- block repos in the middle of cycle
- or even remove packages/repos from users-system when we get to know about bad issues that put users considerably at risk (worst case scenario).
decision making
We need a team that does the reviews and has the power to add and remove repos.
related issues
- recording from which archive a package came on to the system?
- would be nice if launchpad allowed filing bugs against packages *in a particular archive*, or against the archive itself (as with distros)
- showing download counts etc would be nice
- some gap or confusion between PPAs vs -backports (PPAs are not currently suitable for production use (unsigned) (ScottK).
- part of the whitelist process should avoid conflicts between multiple white-list places
- package naming: repos should have reserved names for packages they provide, and then have a prefix for new ones they might make
- - eg openprinting: all packages are prefixed with openprinting-foo --could use a simple script to detect name conflicts as well as file conflicts
- key managment requirements in the policy (like having a archive key that is just
- used for signing) -- in case of a key compromise we push a security update to apt-install-data that revokes that key
- review before each release
- update manager needs to be smarter about updates, especially between distro releases
- - repo no longer whitelisted because it doesn't have new versions - repo no longer whitelisted becaues it is known to break with new release - when the repository starts behaving badly
- -- then we need to remove their key before updating their software
- - repo no longer whitelisted because it doesn't have new versions - repo no longer whitelisted becaues it is known to break with new release - when the repository starts behaving badly
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...
- - goal is to reduce burden of whitelist, also maintainer scripts as much as possible
- many vendors might only care about LTS releases (especially server people)
- speaking about the server, should we have a way for this too (cli ui?)
Use cases
Two main use cases:
- Stuff like Picasa (we trust Google to some extent, but it's nonfree software, Google wants to host it themselves. They don't want to use PPAs or have other mirrors)
- Adobe software is similar. Dell/Google/etc wouldn't use PPAs anyway
- Partner repository shouldn't really be special
The partner repository is special - ISVs go through rigorous testing to participate and are held to a high standard how do we ensure that the 3rd parties do the same? They, at a minimum need to participate in the Ubuntu ISV program (JohnPugh)
- seems reasonable for ISVs who participate in this to participate in Launchpad bug reports for their repo if we sign it
there needs to be a rigorous certification program for ISVs to participate - (JohnPugh)
Launchpad integration
- launchpad should be the place users go for bugs in third party repos, but it needs to be clear
- use "distribution" mechanism?
- also problem of packages from multiple sources (eg from backports and latest ubuntu and so on) (ScottK) - Third party repos shouldn't provide packages that are also in the official archives - that avoids this problem.
Jaunty+1,2:
- no maintainer scripts