UbuntuHelp:ThirdPartyApt
来自Ubuntu中文
 |
点击翻译: |
English |
请不要直接编辑翻译本页，本页将定期与来源同步。 |
目录
ThirdPartyApt
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 distributions (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. Currently ISVs which target Ubuntu create their own, usual proprietary, sometimes common, installation infrastructure. This infrastructure may not be as robust as DPkg and may introduce problems into a user's system as a result of its work. This may install files onto the user's system which are never removed during uninstall. They may not even have uninstall options. This also causes an inconsistency for users of our platform. They have no central interface by which to view currently installed third party software. Each product may have its own auto update mechanism. All of this causes the user a hassle at some point. Some more savvy third parties provide .deb files which the user can install simply by double clicking and launching with GDebI. These ISVs are not very common. They provide their users a valuable service, but the picture isn't totally rosy. Generally .deb files are split into pieces, depending on the function of the package. This requires the user to manually download a .deb for perhaps -common, -core, -art, -kde, -gnome. It also doesn't provide all of our platform services to the user. These ISVs probably desire some way to automatically advertise updates to their users. Apt and our update-notifier are perfect candidates for this. Even fewer third parties actually provide apt repositories for their packages. These packages are generally the best, but still not perfect. The user is required to copy and paste an obscure looking URL, or multiple, into either a text editor, or Synaptic's Add Repository interface. The same has to be done for the apt-key which allows access to the repository. These manual steps are more complicated than it needs to be. ThirdPartyApt seeks to bridge the delivery of an apt repository link to a user's desktop. ThirdPartyApt on its own does not force ISVs to use it. If the framework exists, and is well supported by Ubuntu, then perhaps ISVs will consider automatic updates and integration a service to their users. If not, the situation doesn't change, but there's no harm done.
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 prompt the user for permission to install the software. The user should be able to accept and 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 installed software should track updates from the ISV automatically and integrate into the existing infrastructure. Update-notifier should notify the user when the ISVs software is updated. For Ubuntu specific repositories, ISVs currently must give elaborate instructions for users to setup and enable the repository (eg: here for Wine, or here for Google).
Design
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 here. The APT file is formatted with standard DPkg stanzas. Each stanza contains a repository URL and filters describing what type of platform this URL is suitable for. Consider the example stanza:
Architecture: i386 Distribution: Ubuntu Codename: breezy Release: 5.10 Archive: http://us.archive.ubuntu.com/ubuntu breezy universe Install: photoshop Pin: photoshop libphotoshop0
The first four tags, Architecture, Distribution, Codename and Release specify the specific system that this stanza applies to. Each of these are read and tested against the user's system. If the user's system does not match, the stanza is ignored. This allows a single .apt file to specify delivery of an apt repository for multiple distributions and releases. A seperate stanza could be constructed to apply to Ubuntu and/or Debian, pointing to different archives.
- Architecture: Filters the stanza to the specified apt archive name. Examples would include i386 and/or powerpc.
- Distribution: Filters the stanza to only be applied to systems where the LSB Distributor ID matches. The command `lsb_release -is` returns this.
- Codename: Filters the stanza to only be applied to systems where the LSB Codename field matches. The command `lsb_release -cs` returns this.
- Release: Filters the stanza to only be applied to systems where the LSB Release field matches. The command `lsb_release -rs` returns this.
Archive lists the APT archives to add to the sources.list file. Install specifies which package or packages to install from the archive, separated by spaces. Pin describes which packages should be pinned. Basically this means they should override the default Ubuntu stuff. The resulting file is then signed with the same private key used to sign the Releases file of the archive. Signing of the file is mandatory. A guarentee of a single identity must be available from the .apt file itself all the way to the installing of the packages. The public key required to be added to apt-key is then appended to the end of the .apt file. The first line of the file is then set to "#@application/x-apt 0". This allows mime magic to be used to detect the file type properly. All of this is mandatory, and the client implementation should reject a non-compliant file. The "0" following the mime type is the version number of the Apt file specification that the file conforms to. As breaking changes are made, we increase this number. This number will stay 0 until the specification is actually put into use.
#@application/x-apt 0 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Architecture: i386 Distribution: Ubuntu Codename: dapper Install: photoshop Archive: deb http://archive.adobe.com/archive-ubuntu dapper multiverse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPICNRTZ5+YJ1b+YRAvDoAJ9+NBnSPLa32h7J+tbgisWrh58C2QCdHHwv <etc> =z7nf -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.2.2 (GNU/Linux) mQGiBD/G9AgRBACZ519LX9cdoyJA+7gmWC+mUsiyPhnmMWu4uOg0M+vb/JPtDdfc <etc> =pIE5 -----END PGP PUBLIC KEY BLOCK-----
The above is an example of a final, signed, .apt file.
Method
A program is provided to handle the .apt file type. When this program launches a .apt file, it strips the mime type, verifies the signature, exports the public key, 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 included public key 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. -- The implementation could remove the repository and key after a successful install if upgrade tracking isn't requested. -- The implementation could set pins for the repository to only allow the requested package plus dependencies to be installable. This might prevent common errors in third party packaging from overwriting Ubuntu packages. Just a fail safe, not a security feature. 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. Obviously, a user should not confirm a package installation which he didn't expect to happen: ie a web site opening a .apt file automatically. This presents another interesting trick, by which a spoofed website could open it's own .apt file "quicker" than the exected web site, thus tricking the user into agreeing to the top-most instance of the confirmation dialog. To work around this, I suggest that if two instances of the .apt file handler are opened at the same time, the second should do nothing and the first should fail. Keep in mind that security with this feature is no worse than the current system, where users blindly copy and paste terminal commands with root permission or give Synaptic instructions.
Related Pages
- GAptI
- ThirdPartyPackages
- https://wiki.ubuntu.com/aptgetinstallprotocol
Originally created by: Jerry Haltom
