ThirdPartyApt
|
Size: 4229
Comment:
|
Size: 4554
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 62: | Line 62: |
| * '''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. |
Using Third party packages with Ubuntu
This is a random idea I had.
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.
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 user should click on such a link, be provided an explanation of what they are about to install. The installed software should track updates from the ISV automatically and integrate into the existing infrastructure. We already provide Apt for this. An ISV can provide an Apt repository URL for the user which accomplishes most of this.
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 one possible way.
ThirdPartyPackages specification may also be of interest.
Introducing the .apt file format
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 <blah> =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.
Archive lists the APT archives to add to the sources.list file.
PublicKey contains a GPG public key to trust for package installation.
Install specifies which package or packages to install from the archive.
Method and Madness
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 packages specified by Install are installed.
Related Pages
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.
ThirdPartyApt (last edited 2009-02-05 23:50:29 by 207)