Manifest proposal

From HelpDeskWiki

Table of contents
1 Synopsis
2 Introduction
3 Suggested features
4 Administrative issues

Synopsis

There are a number of common procedures which frequently involve a lot of manual work; this manual work would be unnecessary if software vendors provided the appropriate information in a standardized format. These procedures include, among other things, configuration of firewalls; configuration, (un)installation, updating, patching, and repair of applications; identification and control of log files; identifying files and registry entries needed for backup; descriptions of internal program settings; and so forth. Use of a properly-designed standard machine-readable manifest file could allow full automation of all of these procedures, thus bringing the equivalent of the plug-and-play concept to software management. Once the idea of a manifest is accepted, it is easy to see that there are many things that it could cover. The purpose of this proposed project is to define exactly what is covered, and the format of the manifest file, and to get it accepted by the software industry, along with sample programs to generate and check manifest files, and perform all of the operations that are supported.

Introduction

HelpDesk has recently been doing a lot of security-related stuff, and has been learning a lot. For instance, he set up several small networks for a business, with internet access locked down except for authorized sites. This required finding out what sites the antivirus auto-update software, etc., wanted to connect to for updates. He had to find this out the semi-hard way, by watching the on-screen status messages to see what URLs were mentioned. Reverse-engineering, however trivial, is hardly a professional way to do business, especially when it must be done with every single internet-capable application running on a system.

HelpDesk had already been interested in knowing more about automating installation and configuration of Windows and various applications. As a result of this and other issues, he had the idea of creating this wiki to, among other things, document things like URLs, ports, security-related application tweaks, and so forth, including means of automating much of the tweaking and installation. Much of this information is needed for use with firewalls and anti-malware software ("is this part of an authorized package?"), etc.

He finally realized that this is the WRONG way to go about it. The RIGHT way to go about it is for each application vendor to produce a manifest file (in XML format, presumably) which describes all pertinent information about a package so that an OS, firewall, system management program, enterprise management program, automated installation or uninstallation package, etc., will automatically have the information needed to perform these various activities. This should be a large step towards the maturity of the software management process.

Suggested features

Here are some of the features that should be considered for the proposed manifest; those that apply should be considered mandatory.

  • Digitally signed by the publisher (an unsigned manifest should be a big warning).
  • A complete list of all ports, protocols, and addresses used, both inbound and outbound, using a language that can provide all of the information needed by both the simplest NAT routers and the most sophisticated rule-based content firewall software or firmware. Example: Norton's LiveUpdate has about 3 different URLs that it tries in order to retrieve updates. This information is necessary in locked-down environments where only explicitly authorized traffic is allowed out. As another example, HelpDesk has been beta-testing a TV-recording application, which uses a number of background processes. This application self-publishes itself with Windows Firewall, but not with Norton Firewall or other firewalls, which ask for approval for about 5 different processes the first time the program is started up. There's one more process which doesn't run until it's time to record a show, and if the user is away at this time, the very first recording will not occur. With a manifest, any firewall could request approval for all parts of an application at installation time. This same TV-recording application uses a DLL which is picked up by at least two different anti-malware apps as adware. The DLL is apparently used to transfer TV listing data, not ads. A properly-formed manifest could be used by anti-malware applications to distinguish between the DLL used in this case, and the same DLL used in standard adware situations.
  • A command-line and instructions for silent (invisible) installs, unattended installs, minimal-user-input installs (go/no-go only), or partial user input installs (user can change things that the sysadmin doesn't pre-set). Also, the same for uninstalls. This should apply to updates/patches, as well. At present, there are a significant number of sites which exchange information on how to do this with various software packages; many people spend long periods of time figuring out how to do this stuff, often duplicating work done by others. Example: A computer store which pre-installs unregistered WinZip on new systems; the technicians would have to click on buttons for several moments to get it fully installed, unless an automation tool such as AutoIt is used to do the clicking for them. This, of course, would require them to sit down and spend the 30-45 minutes to create and test the script needed.
  • A complete list of services to disable, processes to terminate, and folders, files, and registry entries to be removed in order to totally remove the application, in case the uninstaller isn't working as intended, with separate sections for Windows data (such as the menu order in the registry, and the prefetch folder), user data, and log files, so that side effects can be cleaned up. An example of this is Norton AntiVirus; sometimes it gets sufficiently corrupted that it must be removed manually. Why spend 20 tiresome minutes doing it manually (with the possibility of missing something or messing up), when a REG file (to delete registry entries) and a batch file (to delete files and folders) can do the same thing? If this information is provided as part of a manifest, then a generic removal tool can be written to cleanly remove almost any application (not including subscription/license/registration data, if applicable). Yes, Norton Antivirus is installed from an MSI file, so the use of MSI files is not the answer to this issue.
  • A complete list of things to change to return the application to factory default. Windows Automatic Updates is an example of this; HelpDesk keeps finding new things to do in order to unlock it when it either stops hitting the SUS server or stops applying the updates that it has retrieved. He'd like to be able to create a batch file and reg file that definitively resets it to a known condition. Or better yet, use a generic manifest-based application to do the job.
  • Information on where to find the log file(s) for the application, either for examination, short-term backup, or cleanup. The section which documents program settings should include the setting for changing the log file location, if supported.
  • Information on what to back up, so that the application can be installed on the same or different computer with a fresh OS, and the data then restored, to return it to exactly the same state as before, or as close as is practical or reasonable, not including log files, temporary files, and other settings and files which would automatically get re-created. HelpDesk is involved in setting up backup procedures for several businesses, and each one seems to require an interminable amount of tweaking in order to eliminate files that come with the various programs installed on each system, yet include files which are critical for the business.
  • Flags which indicate whether the application conforms to various Windows Vista logo requirements or other requirements that seem desirable to the designers of the structure of the manifest file. For example, the application (and only the application) should go into %PROGRAMFILES%; data, configuration info, and log files should be under %ALLUSERSPROFILE% or %USERPROFILE%, as appropriate; and putting anything under %SYSTEMROOT% should be an absolute no-no; only system components from Microsoft should go there. Also, some applications assume that the %PROGRAMFILES% folder is always named "Program Files", or is always on "C:". If the application does not conform but can be made to conform, then the configuration description for this should be provided.
  • Document various registry and other program settings, so that an administrator can easily preconfigure or reconfigure an application exactly as desired. Doing the ol' "let's change this setting, and see how and where the program saves the setting" is not exactly a professional way of doing things. There should be both a summary and a detailed description of every possible setting which an administrator might be interested in. It is easy to find short descriptions online of various registry settings, which often don't make much sense until they are tried (and sometimes don't even make sense afterwards); rarely seen are detailed descriptions that actually tell you what you need to know about the setting. Be certain to mention which setting(s) or control(s) within the application this is tied to. Be sure to mention how each setting affects security, usability, remote management, performance, side-effects (why would someone not want to change it), and other such things; the manifest structure designers need to compile a complete list of attributes to describe.
  • Details on how to automatically check for and install updates or upgrades on a system-specified schedule, in a manner similar to Windows Automatic Updates, which does not require that the program always be running in the background, and how the system can determine the status of the update attempt.

Administrative issues

  • The combination of the file extension and structure used for the manifest should be copyrighted (or whatever), so that others can't legally add unauthorized format extensions, and thus confuse things.
  • On the subject of format extensions, there should be an administrative mechanism for requesting format extensions to be added to the structure. The original structure design and the design of format extensions should both be community-driven, in an effort to minimize the number of deleterious or dead-end designs.
  • Prior art: There have been somewhat similar things, namely *.SDN files for the Software Distribution Network, which, if HelpDesk recalls correctly, included various details about the size, OS and other minimum requirements for an application, and FILEID.DIZ files, which, as HelpDesk recalls, are mostly single-line and long descriptions of the application. Both of these were created in DOS days. It's much closer to Microsoft's *.MANIFEST files, which seem to be intended mostly to provide info on shims and customizations to apply to an application. Those *.MANIFEST files might be suitable as a foundation for the manifests proposed by this article, either using the same or a similar filename extension and structure.
  • Perhaps the Common Criteria Project (http://www.commoncriteriaportal.org) could get involved, since there seems to be some relevance.

Feel free to add more here or put a suggestion on the Discussion page. Can we get this rolling, or is there a similar project already underway? This article is written from a Microsoft Windows viewpoint, but there is no reason to believe that the same issues and solutions don't apply to any other OS.

Retrieved from "http://www.local.nu/HelpDesk/index.php/Manifest_proposal"