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

[Rob Mensching]

I *think* Sean resolved the secure variables a long time ago (although maybe only via the native API). Hidden should work (if not, good feature for someone to implement).

Short replies here. Complete answers here: https://www.firegiant.com/services/


-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Edwin Castro via wix-users
Sent: Friday, December 27, 2019 10:46 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Edwin Castro <egcastr at gmail.com>
Subject: Re: [wix-users] Looking for Advice/Opinion on Approach

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/
>

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/