Moving from test win32 MSI packages to production ready

[coderman]

Moving from test win32 MSI packages to production ready

This is important for updater assisted bundle and network
installer packages. [0]

The new MSI packages in testing need a few changes before
any public distribution of them is reasonable. The other
changes mentioned below can wait until after an initial
MSI based bundle is announced and distributed.

There are also some significant differences between these
packages and the existing NSIS based installers:
a) Windows 2K SP2 is the minimum supported OS version due to
   the Microsoft Installer switch.
b) Only local per user installs are currently supported. [1]

Work in progress in progress for minimal first distribution:
 [code drop ETA end-of-week. public www pkgs next month?]
1) Add all of the various LICENSE files and disclaimers into
   each package, every time, for all necessary languages
   OR
   Include new license file package so that we don't need to
   track and maintain redundant license data in the packages
   or bundles individually. [2]
2) Add edmanm's Vidalia bundle NSI installer logic for Tor
   button installation into the bundle installer exe.
3) Provide the quick and thorough uninstall utility with
   bundled packages. [3]

Near term changes of high priority likely to prevent some
users from installing or being able to use the new packages:
0) At some point the keys used for the Thandy repo and sent
   with the client exe need to be updated. That point may or
   may not be before the first release, but probably should?
1) Finish support for native mingw32 python to eliminate
   dependency on Microsoft Visual C++ Runtime in Thandy and
   other apps. [4]
2) Implement changes to bundle package WiX specs for feature
   selection configuration via command line and registry.
3) Integrate localization support into WiX specs if needed
   for that feature and integrate multiple localization
   bundling into the installers. [5]
4) Support install as service and for-all-users based
   deployments of the MSI packages and bundles. [6]
5) Add optional support for Marble Vidalia widget; bonus
   points if it can detect 3D render frame rate and adjust
   on the fly.

Additional features that may or may not be needed:
a) Implement Thandy updater support for service installs
   and all bundle component packages.
b) Include Tor with the network installer for initial
   downloads routed through Tor instead of direct only.
c) Support for native 64bit applications and packages.
d) Support for SteadyState deployments. [7]
e) Including current cached directory consensus info and
   descriptors with frequently updated bundle installers
f) Provide hooks for users to use bridge descriptors and
   stay within strict firewall constraints for both the
   network based installation and the first time bundle
   installation.

[ref]:

0. Alpha packages with untrustworthy Thandy signatures:
https://data.peertech.org/files/demo/updater/index.html
Feedback welcomed!

1. Practical impacts of new Microsoft Installer packages:
the primary concern aside from higher minimal supported
operating system version is the path under which Tor
and bundle components reside. For the assisted updater
to be able to run from Vidalia and with least privileges
the program files as well as application data must all
reside under CSIDL_LOCAL_APPDATA, aka:
%USERPROFILE%\Local Settings\Application Data\, aka:
C:\Documents and Settings\<user>\Local Settings\Application Data\

2. License package or just hack existing .wxs files for each?
There are two reasons I am leaning toward a license
package. An infrequently updated license package makes
the bandwidth savings for Thandy updates even more useful
given the large amount of license data in a single kernel
image associated with all of the packages used in the Tor
VM file system image. This would also prevent needless
duplication of license data in the bundle and network
installers.

3. The problem with un-installing or repairing a bundle:
Since we're now shipping the guts of Tor and all its
bundle related dependencies in MSI packages we need
something more than the default MSI package remove via
control panel option for the bundle and network installer.
The MSI package utility also requires that .msi packages be
available on the file system for repair.
The MSI package utility also requires that package removal
without a local copy of the .msi package use the Product ID
instead of .msi package file.
The work-in-progress bundle package utility is a small
stand-alone native exe that interacts with msiexec, the
registry, and can assist with securely updating and
repairing all of the MSI packages distributed.

4. What is the "Microsoft Revenue Generation Feature/Tax":
It would be ideal if anyone that wanted to build an entire
set of bundle packages and installers from source and
redistribute everything they need without anything more
onerous than "open source" [see 2] derivative work
constraints and require no licensed software to build it.
Microsoft conspires to guarantee that you'll be using a
licensed copy of at least the most recent Visual Studio C++
for building your distributable executables. Note that any
package that ships with the Visual C++ runtime libraries as
a side by side assembly built with licensed VC++ cannot be
built by anyone without their own licensed copy of VC++.

5. Localized MSI packages with WiX:
This boils to mapping as much as we can in terms of text
presented to the user from the default WixLocalization
element specification. Whatever can not be deferred to by
default in the standard WiX UI would then need to be added
from sources when building the packages.

6. Installation and upgrades for all-user or service setup:
The default local install per user mode of deployment is
preferred because it does not require administrator rights
nor will multiple copies of the same product series on the
same host conflict with each other. The ability to install
as a service that launches at boot and/or make parts of the
packages available to all users requires at least:
  a) Installing into a local, persistent location and not
     under any User owned Application Data folders.
  b) Prompting for escalation during initial bundle install
     and indicating admin requirements in MSI package.
  c) Moving the Tor update process out of Vidalia and doing
     it from service or manually after user notification.

7. Microsoft Windows SteadyState (part of Shared Access
   Computing)
  http://www.microsoft.com/windows/products/winfamily/sharedaccess/whatis/default.mspx