[wix-users] Looking for Advice/Opinion on Approach

Edwin Castro egcastr at gmail.com
Fri Dec 27 10:45:39 PST 2019


The issue of hiding property values has been asked previously

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-secure-Bundle-Variables-td6348018.html

I don't think there is an official solution for this yet.

You can make Variables on the burn side Hidden and you can make Properties
on the MSI side Hidden. I have not checked yet if that is enough to ensure
the logged command lines are appropriately obfuscated as a result.

Do remember the following

https://docs.microsoft.com/en-us/windows/win32/msi/msihiddenproperties

Especially the bit about the Debug policy.

My gut says it might be better to encrypt sensitive information in a custom
BA, pass it encrypted to the MSI, then decrypt it in an immediate CA.
Unencrypted sensitive information should be stored in hidden variables and
properties.

--
Edwin G. Castro



On Fri, Dec 27, 2019, 08:44 Bryan Dam via wix-users <
wix-users at lists.wixtoolset.org> wrote:

> I've spent the last few weeks looking at our existing WiX installers and
> doing different proof of concepts to get a better understanding of our
> options and their pros and cons.  Before I finally commit to one of them I
> figured I'd throw it out there and see if anyone with more experience was
> willing to lend their advice.
>
> Here's the situation:
> Our product has three components: a client, server, and agent.  Each have
> and will continue to need their own WiX-created MSI installers.
> The Server install includes a bunch of custom UI to configure IIS
> (including cert generation/selection) and create a SQL database via a bunch
> of custom actions.
> The Server requires the .NET Core Hosting Bundle (not just the .Net Core
> runtimes) be installed as a pre-requisite.
> The Agent installer installs a service that the installer UI allows the
> user to configure it to run as System or provide service account
> credentials to use.
> In order for certain functionality to work the agent needs to be installed
> on the server with a service account.
>
> The goal is to improve the server install user experience by installing
> the .NET Core pre-req (we have lots of disconnected environments), the
> Server, and optionally install the Agent using a seamless UI.
>
> Things I've looked at:
> 1) Burn with one of the standard bootstrapper applications.
> Due to the IIS/SQL configuration we need to get a bunch of input from the
> user via the installer UI.  The only option here was to use the MSI's
> existing internal UI which 'works' but was deemed by my team as not
> sufficient from a UX perspective.  They want the whole thing to feel like a
> single installer versus chaining 3 different installers together.
>
> 2) Burn with a custom bootstrapper application written in C#.
> Recreate the Server and Agent installer UIs in C# to get the needed
> parameters and call each installer silently with those parameters.  Right
> now this is viewed as the most promising solution.  For this to work we
> need to pass the credentials to the Agent installer which gets properly
> hidden in most of the logs but is shown in plain text in the actual bundle
> package's command line.  Maybe there's a solution there but I'm not
> optimistic.
>
> 3) Making the Agent a feature/component of the Server install.
> Haven't gone too far down this road but this would solve the 'password in
> the log' problem above but I think creates other issues.  Doesn't solve
> installing the .NET Hosting Bundle and the agent still needs its own
> stand-alone installer which could make things tricky: what if someone runs
> the agent install on a server that installed the agent as a feature?
>
> Anyhoo, sorry for the wall-o-text there but if anyone has
> thoughts/opinions/advice I'd love to hear it.
>
>   Thanks everyone,
>            Bryan
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>



More information about the wix-users mailing list