[wix-users] Logging password variables using WiX managed bootstrapper - A serious blocking issue

Wed May 1 07:46:51 PDT 2019

This seems to me to be exactly parallel to wondering what we should do about a user who accidentally types his password into the wrong window and it is now temporarily in a word document or something.

Keith Douglas

Programmer-Analyst - IT Operations Services, Corporate Services Field
Statistics Canada / Government of Canada
keith.douglas at canada.ca / Tel: 613-854-5589

Programmeur analyste - Services opérationnels de la TI, Secteur des services intégrés
Statistique Canada / Gouvernement du Canada
keith.douglas at canada.ca / Tél. : 613-854-5589 

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Edwin Castro via wix-users
Sent: May-01-19 10:40 AM
To: manogna reddy <manogna657 at gmail.com>
Cc: Edwin Castro <egcastr at gmail.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Logging password variables using WiX managed bootstrapper - A serious blocking issue

Yes. If variable names are case sensitive, as expected, then you must
specify a hidden variable for each and every possible permutation of lower
and upper case characters and write some code in your BA to check all
possible variables for a value so that you know which one to use as well as
some strategy to decide which value to use if the user specifies more than
one variable.

If variable names are case insensitive, then the behavior you are seeing
should be considered a bug and a bug should be filed. Contributing a fix
would be better!

As I previously mentioned, I expect variable names to be case sensitive.
Trying to support case insensitivity sounds insane. I don't expect WiX to
accept a change to make variable names case insensitive but I suppose you
could try.

Teach customers to use the CapsLock key or something. All kidding aside,
the current behavior and the resulting concern already exists for bare
naked MSIs. Anybody with experience specifying public property values on
the command line for MSIs would already know that these property names are
case sensitive. This case sensitive public property names for MSIs has been
a thing since the Windows Installer was introduced. This isn't exactly new.

Is it really true that users are concerned over this? Or is it really
management that is concerned over this? My experience says that
non-technical users simply double click an installer to install so
specifying variable values on the command line is not an issue. My
experience says that technical users know enough to specify variable names
using the correct case. Your installer should already fail with some
message saying that PASSWORD was not set. Perhaps concerned users can be
directed to delete logs for that failed install attempt.

--
Edwin G. Castro

On Wed, May 1, 2019 at 3:32 AM manogna reddy <manogna657 at gmail.com> wrote:

> Hi Edwin
>
> Thanks for the reply .But the users are concerned with password getting
> exposed if the case of the variable differs .Is there any way to remove
> logging of the below command line from the log file
>
> On Wed, May 1, 2019 at 2:12 PM Edwin Castro <egcastr at gmail.com> wrote:
>
>> I would expect variable names to be case sensitive in a bundle just like
>> properties are in MSI. Mixed case and lower case properties are considered
>> "private" and cannot be overridden on the command line. PASSWORD, password,
>> PAssWord, and PassWorD are different properties and only one of them is
>> "public".
>>
>> I would have expected burn variables to work similarly. I see the
>> documentation says that for a variable to be overridable you must set
>> Overridable="yes" so the case of the variable name doesn't matter here.
>> Unfortunately, the documentation doesn't indicate whether variable names
>> are case sensitive as they are in MSI.
>>
>> The behavior you're seeing seems to indicate that they are treated as
>> case sensitive. That would suggest that your users will need to be specific
>> about case when specifying command line arguments.
>>
>> --
>> Edwin G. Castro
>>
>>
>> On Wed, May 1, 2019 at 12:11 AM manogna reddy via wix-users <
>> wix-users at lists.wixtoolset.org> wrote:
>>
>>> A small correction to the mentioned scenario
>>>
>>> When I try to pass the variable '*password'* from command line , value
>>> will
>>> be shown  in the  log file as below . In my scenario it should hide the
>>> variable value irrespective of case
>>>
>>>   *[61D0:39C0][2019-05-01T12:07:15]i009: Command Line:
>>> '"-burn.clean.room=Setup.exe" -burn.filehandle.attached=596
>>> -burn.filehandle.self=648 /s /i USERNAME=abc  password=12345'*
>>>
>>> On Wed, May 1, 2019 at 12:40 PM manogna reddy <manogna657 at gmail.com>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > I have a variable declared in Bundle.wxs which stores the password
>>> >
>>> > *<Variable Name="PASSWORD" Persisted="yes" Hidden="yes"/>*
>>> >
>>> > When I try to pass the variable '*PASSWORD*' from command line , value
>>> > will be hidden as below which is working as expected
>>> >
>>> > *[61D0:39C0][2019-05-01T11:57:15]i009: Command Line:
>>> > '"-burn.clean.room=Setup.exe" -burn.filehandle.attached=596
>>> > -burn.filehandle.self=648 /s /i USERNAME=abc  PASSWORD=*****'*
>>> >
>>> > When I try to pass the variable '*password'* from command line , value
>>> > will be shown  in the  log file as below . In my scenario it should
>>> hide
>>> > the variable value irrespective of case
>>> >
>>> >   *[61D0:39C0][2019-05-01T12:07:15]i009: Command Line:
>>> > '"-burn.clean.room=Setup.exe" -burn.filehandle.attached=596
>>> > -burn.filehandle.self=648 /s /i USERNAME=abc  PASSWORD=12345'*
>>> >
>>> > *Is  there any way to achieve this? Because I can't force the users to
>>> > specify varaible name in specific format.*
>>> >
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>>

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