ThirdPartyApt

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/apt-third-party

• Created: JerryHaltom

Introduction

ThirdPartyApt defines a file format that ISVs can publish on their web sites and distribute to users to download their software.

Rationale

Third parties should be able to distribute programs for installation on Ubuntu or other Apt based distros (especially Ubuntu). They should be provided tools to make installation, integration and maintenance of their programs easy. We have existing infrastructure to provide to them, but need to do so in a consistent way while providing an easy to use interface.

Scope and Use Cases

The main use case is simple. A user should be able to be provided a link to click on by a third party ISV which will start the installation of that ISVs software. The ISV may provide this link on a Download page, or after an accepted payment transaction as been processed.

The user should click on such a link, and be provided an explanation of that they are about to trust the third party to install software onto their system. The installed software should track updates from the ISV automatically and integrate into the existing infrastructure.

Design

We are missing a link between the act of clicking on a link on the web and the package itself being installed. Here I seek to provide a possible way.

A file format should be created that encapsulates a number of pieces of information necessary for installing a remote application or set of applications. This file format is called a ".apt" file.

The APT file is formatted with standard DPKG stanzas. Each stanza contains a GPG key, repository URL and filters describing what type of platform this URL is suitable for. Consider the example stanza:

Name: Figlet
Architecture: i386
Distribution: Ubuntu
Codename: breezy
Release: 5.10
Archive:
 http://us.archive.ubuntu.com/ubuntu breezy universe
PublicKey:
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 Version: GnuPG v1.4.0 (GNU/Linux)
 .
 mQGiBEFEnz8RBAC7LstGsKD7McXZgd58oN68KquARLBl6rjA2vdhwl77KkPPOr3O
 <etc>
 =C9XB
 -----END PGP PUBLIC KEY BLOCK-----
Install: figlet

Name species a friendly name to call the package. This appears in the UI.

The next 4 tags, Architecture, Distribution, Codename and Release specify the distribution that this stanza applies to. Any can be omitted. Only the filters that are present are applied. If you want the stanza applied to all Archs, remove Architecture. Most of these are probed from lsb_release. This will allow one .apt file to be generated for multiple distributions or versions thereof.

Archive lists the APT archives to add to the sources.list file.

PublicKey contains a GPG public key to add to apt-key to trust for package installation.

Install specifies which package or packages to install from the archive, seperated by spaces.

Method

A program is provided to handle the .apt file type. When this program launches a .apt file, it parses all the stanzas and determines which applies to the current environment. It then walks the user through a few simple questions asking if they are sure they want to trust the PublicKey to install software onto their system. After the user has confirmed all the steps, the public key is added to apt-key and the packages specified by Install are installed.

Implementation: ["GAptI"]

Security

The obvious security considerations do not go away. Yes, a malicious software provider could provide a .apt file which adds a trusted key and repository to the user's apt-key and sources.list. Is this a problem? Users want to install third party software. Providers want to provide it. Yes, this software may make system-wide configuration changes. Yes it may REQUIRE root to run. The best we can do is provide a proper interface by which the user can manage these things, and make him as aware as possible of the consequences. Forcing third parties to come up with their own packaging method isn't it, and that's what they do now. Users have to drop to the command line and run a .bin, or a .run file, or whatever the provider provides. These packages don't integrate into the system. They can break things, install software in the wrong location, overwrite existing files. But people use them, now.

In that vein, when the "are you sure" dialog opens, if the key is not currently trusted, the window should very explicitly state that they are about to trust the provider of the software to provide updates. I'd suggest the OK button is disabled for the first 5 seconds, forcing the user to actually wait, perhaps reading the message.

Related Pages

• ["GAptI"]

• ThirdPartyPackages

• https://wiki.ubuntu.com/aptgetinstallprotocol

Comments

• MatthewPaulThomas: This seems to be a reinvention of [http://autopackage.org/ AutoPackage], but with not so much portability.

• ArwynHainsworth: You mean [http://autopackage.org/ AutoPackage] is a reinvention dpkg/apt-get, right?

• ArwynHainsworth: The proposed idea as it stands has a HUGE security flaw. If the program that handles .apt files can add any generic repository is sees in the file, what is to stop l33tHax0rs & co. from creating a repository with a deb of a slightly patched kernel (or any other core system deb)? He doesn't even have to get the user to install it directly, all he has to do is get the user to add his repository (with a completely harmless and useful deb) and wait for the user to update. Solution: 1) Remove the Archive: tag completely. or 2) Only allow repositories to be added if they are on a whitelist.

• Killerkiwi: Id vote for only allowing the install if the list repo is in the sources.list else just display an error, "You need to enable the following repo to install 'foo'"

• JohnMccabeDansted: If you want to run 3rd party software you pretty much have to trust the third party, unless you constrain the software using something like Plash or SysTrace. I guess a whitelist of third parties might be useful, or a whitelist of public keys owned by people trusted to approve new repositories.

• JerryHaltom: The last comment explains it. There is *no* answer to installing software on a user's PC that does not leave open the possibility for that software to be untrusted. None. It is currently an unsolvable problem. The entire goal is to install software that isn't already in Ubuntu, and thus it can't be considered trusted by Ubuntu. Either you make installing untrusted software impossible, or you ignore the problem. What this seeks to do however is provide an easier way, to do something people will do already.