From GameOver

This program and all design concepts are (c) David Supuran 2007 <http://www.iphonegameover.com>

Contents 1 Problem 1.1 Source 1.2 Community Involvement 1.3 Features 2 Solution 2.1 Source 2.2 Community Involvement 2.3 Features

Problem

AppTapp - it is currently the main application manager and installer to use, but it comes with a large array of problems.

Source

Currently AppTapp (known as Installer.app) provides no source code (complete closed source) for it's user interface and client software. There is no documentation provided on any functionality of the software including it's communication and all related server side tools.

Community Involvement

There has been tons of feedback as to the currently used client installer for improvements, features, and bug-fixes which are not addressed in a timely manner which raises a problem of community involvement for an application which should be actively maintained.

Features

• The client is provided little updates and bug fixes
• It provides many obstacles and ambiguity to developers who wish to add new packages such as package generation and maintenance.
• The repository servers are maintained with manual scripts and little support which adds more room for error and delay.
• The client often hangs and/or has delays while trying to run due to it's inferior package refreshing.
• The client has a very primitive and basic feature set which is not scalable.
• Repository server structure is limited and not built for automatic scaling or automatic fall over for down providers.
• Certain practices are inefficient and redundant.

Solution

goPkg - The iPhone/iTouch Package Repository

Source

The solution will provide full open source software. This will allow auditing, as well as the inclusion of more great minds to contribute ideas to the project which improves the functionality and provides more back to the community.

Community Involvement

Due to the open source platform and extensive design, this project thrives around the ideas and best practices of the community which give the most valuable results to the end users.

Features

For:

end users/clients

• Better traversal and user interface to more efficiently perform operations you care about - Installing, Updating, and De-installing applications.
• the client application will bring a multi-threaded environment which will support refreshing packages and providing notifications in the background, instead of making you wait. No more hanging windows.
• Automatic refreshing of the packages database will be based on a set TimeToLive (TTL) instead of refreshing almost every time the installation client is opened. This smart refreshing saves both sides bandwidth and processing power.
• Search feature - with scalability kept in mind, you will be able to search the packages with basic criteria such as package name, package description, package owner, repository owner, and by package category.
• Package Comments - help give users a brief overview of user responses on a particular product or provide direct feedback to the developers/package maintainer themselves in a public setting. It is still up in the air as to whether package maintainers (owners) should have access rights to delete individual comments or not. This could be used to delete legitimate negative issues with the product and censor the usefulness of the comment system. More feedback is needed on this.
• Package Voting - Each package will be capable of receiving votes based on a set scale to determine how good, useful, and overall accepted it is by the community which uses it.
• Each package will be reported as installed as [name]-[version] with the description to follow and/or a separate page with more information.
• Manually downloaded packages will be able since the package download files will be stored in one base directory. There will be an option to automatically clear downloaded package files on exit to save space.
• For the purpose of flexibility, users will be able to install older/archived versions of software for whatever reason. This provides more control in the user's hands, but still the newest version will be installed by default and this is merely an option.

Package Developers and Maintainers.

• Faster response - Packages updates will propagate instantly to all repository servers and be available to anyone who manually or automatically refreshes the package database.
• Revision support - this system will allow you to make revisions of your software based off your explicit software version.
• Package EPOCH - This concept is borrowed directly from FreeBSD's port system.

From time to time a software vendor or package maintainer will do something silly and release a version of their software which is ::actually numerically less than the previous version. An example of this is a port which goes from foo-20000801 to foo-1.0 (the former ::will be incorrectly treated as a newer version since 20000801 is a numerically greater value than 1).

In situations such as this, the EPOCH version should be increased. If EPOCH is nonzero it is appended to the package name as ::described in section 0 above. EPOCH must never be decreased or reset to zero, because that would cause comparison to a package from ::an earlier epoch to fail (i.e. the package would not be detected as out of date): the new version number (e.g. 1.0,1 in the above ::example) is still numerically less than the previous version (20000801), but the ,1 suffix is treated specially by automated tools ::and found to be greater than the implied suffix ,0 on the earlier package.

• Dependencies - a list of required dependencies before the package can be installed. This list will be displayed to the user in a complete listing and required to be accepted/installed before the core package can be installed to prevent runtime issues. If package foo requires packages A,B,C and package B also requires X,Y,Z which is not installed, the user will be asked to install A,B,X,Y,Z,C before proceeding.
• While this product will have many features, future features of the client and server can not be predicted, so an option to require a minimum goPkg client will be added for packages to install to ensure if any non-backwards feature is added and used by a package at a later time, it will not attempt to install [and fail] on a prior version. This helps ensures packages can gracefully operate as they are intended.
• Installer scripts - Each package will have the ability to run installation shell scripts pre- and post- installation to provide extended customized functionality outside the scope of goPkg which will prepare a package for being run by the user.
• Deinstaller scripts - Each package will have the ability to run Deinstallation shell scripts pre- and post- Deinstallation to provide extended customized functionality outside the scope of goPkg which will prepare a package for being removed and cleaned up.
• Forbidden - This will temporarily disable a package from being installed by new users and request current users with it installed remove it from their system for the Description/Reason provided. Package owners may mark a package as forbidden for example in enlightenment of a malicious exploit, fatal problem, or other serious concern that would otherwise need addressed and resolved with a new version before others used it. It is a sort of damage control system.
• Packages will currently receive the following base information (but not limited to): Package name, description, developer's name and email and/or website.
• Package maintainers - These are the users who created and initially uploaded the package that were designated the maintainer. It is currently unknown if multiple package maintainers will be allowed.
• Deletion - Each package maintainer should have the right to delete their package if they choose to do so.
• Retirement - Each package will be given the retirement option which will disable it and optionally redirect users to another package as it's successor. All retired packages will be deleted after a set time (3-6 months possibly?).
• Conflicts - add a list of software that this package conflicts with and can not be installed while the other exists.

Repository Servers

• SHA-256 hash requirement (in parallel with file size of course) instead of inferior hash algorithms and sizes. File hashes are used to verify file contents are not modified by any unauthorized party.
• Master Server - will be defined in a hierarchy where the top level servers are considered {core|root|master} servers. these are defined as servers which will keep a mirror of all packages and have extended responsibility for ensuring the operating of the overall repository network.
• [Slave] Servers - these are defined as leaf servers which have the ability to keep only packages are own and will communicate directly with master servers. Slave servers will be added to the overall pool of active download links for those particular packages they are responsible for. This will help distribute downloads and provide an extra source which might be ideal for some users based on their geographic location.
• Mirror Servers - A list of mirror servers to download from which ONLY provide the package installation files and NOT the hash or other security information for that package to verify the contents of that file. It theoretically should be possible to have a slave server also act as a mirror server. Mirror servers should be able to be controlled from slave servers, otherwise they provide little to no usefulness for the automated design here.
• Server priority - Server selection will be based on a weighted percentage. [need more info]
• Forbidden - Any package can have a vote initiated towards it to see if a forbidden tag should be added to it. A vote can only be initiated by the repository server that owns it or another master server and the vote must receive 50% or more of all total votes for it to be passed; there will be a timeout period (24 hours maybe?) set in case lazy administrators/owners decide not to cast their votes for their set repository server. Once a vote is passed, a package is marked as forbidden with a reason to explain to users why they can no longer install it.
• Malicious software - A package can be marked as malicious by the owning repository or any master repository. Any package which gets marked will have an immediate notification for anyone attempting to install it noting that it is malicious and it is HIGHLY recommended that they do not install it. They will be given the option to install or not install it at their choice after this. Once the software is marked as malicious it will go through the standard voting process for forbidden software.
• Dual hash verify - to help protect against any Repository Server from maliciously corrupting package versions, when a package is installed by a client it is required to verify the SHA256 hash against two separate repository servers. The first server will be selected based off of the server priority algorithm and the second server must be chosen with an unweighted and unbiased random selection assuming there are more than 1 active server to use for this package. If it is unable to connect to 2 servers with (n-1) >= 2 servers, the package will not be installed. Any mis-match in the hashes from the two separate servers will result in both servers being questioned. First both servers will contact the repository owner for that package and check what it says, if it is not the same as itself, the server should voluntarily mark itself as corrupt for that package and notify the owner/master servers of such. The second server will also notify every other owner/master server to ensure this message is not hidden or delayed once it realizes this as well. This ensures both servers check each other and report any invalid findings. If by chance the repository owner is not online and there is a hash dispute, both servers will disable themselves as unverified until it can be settled. In this case a msg will be sent to users who try to access this package saying "temporarily disabled" or similar, so it knows to pick a new server.
• Each server will have their own public/private key pair for certain sensitive communications and signatures of messages for inter-server communication.
• Logs - All servers are required to be able to provide proper statistical logs to any repository which owns packages on that server or to master servers which have access to full statistical logs. Logs will include but not be limited to timestamps, client information, and the file received.
• Users will be stored and mirrored on all master servers.