[wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles

Wed Aug 5 15:27:47 PDT 2020

>  Anyway, I totally understand if Persisted Hidden variables are not
encrypted in the first version of the feature.

I agree with Rob. Can we take the encryption discussion to a separate
thread for #4862? I don't think we should require it for #3704.

On Wed, Aug 5, 2020 at 8:25 AM Rob Mensching <rob at firegiant.com> wrote:

> > If Windows Installer really doesn't protect Hidden variables with
> encryption, then I'm not sure there's value in Burn doing the encryption
> during runtime or at rest.
>
> Reasonable argument but persisted MSI Properties is an oft requested
> feature (that's why my Remember Property Pattern blog post is very popular)
> and doing it with secure variables requires more complicated machinery.
>
> I am of the opinion (and I could be convinced I'm wrong), that protecting
> secrets in memory is overkill. There is always a point somewhere in the
> process where the secret is not encrypted in memory (like being typed into
> a password text box or sent to an external process). So, the goal should be
> to protect the secret from non-authorized users. That's why I thought DAPI
> would work because it prevents a hard drive from being stolen and
> inspected. AFAIK, there is no protecting secrets from users on the machine
> who run processes that operate on those secrets.
>
> Anyway, I totally understand if Persisted Hidden variables are not
> encrypted in the first version of the feature.
>
> Also, I think it is a bit of a hassle for a BA to securely store Hidden
> variables. Namely, it'd have to create a parallel set of persisted
> variables that are updated when their non-secure variables are changed.
> Doable, just a bit of a hassle.
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Sunday, August 2, 2020 4:48 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables
> from related bundles
>
> If Windows Installer really doesn't protect Hidden variables with
> encryption, then I'm not sure there's value in Burn doing the encryption
> during runtime or at rest. It would always need to be decrypted and sent to
> an external process to actually be used which defeats the purpose. At which
> point we should probably copy Windows Installer and say that Hidden only
> protects it from being written to the log. If the BA wants it decrypted, it
> can encrypt it and set a string variable to the base64 value.
>
> On Sat, Aug 1, 2020 at 1:08 PM Rob Mensching via wix-devs <
> wix-devs at lists.wixtoolset.org> wrote:
>
> > > added a warning or something to Variables marked Hidden and Persisted.
> >
> > Or... should we investigate DAPI encrypting Hidden variables in the
> > registry? Just throwing that out there if Jacob (or someone) wanted to
> > noodle on it. I have not thought through the issues to the bottom.
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Rob Mensching via wix-devs
> > Sent: Saturday, August 1, 2020 11:13 AM
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Cc: Rob Mensching <rob at firegiant.com>
> > Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted
> > variables from related bundles
> >
> > Quick historical note:
> >
> > > I feel like the interaction between Hidden and Persisted wasn't
> > > fully thought through
> >
> > It wasn't that it wasn't thought through, the problem was just punted
> > in the first version of Burn. Maybe that's the same thing but the
> > intent was different. <smile/>
> >
> > In the end, we probably should have added a warning or something to
> > Variables marked Hidden and Persisted. Maybe not too late to consider...
> > especially if the values are going to be more obvious in the registry?
> >
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Sean Hall via wix-devs
> > Sent: Wednesday, July 29, 2020 10:46 AM
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted
> > variables from related bundles
> >
> > By "secure", you mean a Variable that is Hidden="yes"? The state file
> > is just as secure as the registry. I feel like the interaction between
> > Hidden and Persisted wasn't fully thought through, hence the issue I
> > created - https://github.com/wixtoolset/issues/issues/4862. I've been
> > following the .NET Core discussion about obsoleting SecureString (
> > https://github.com/dotnet/designs/pull/147)  and I'm wondering if
> > there's actually value in the engine encrypting Hidden variables. I
> > had hoped that MSI was also trying to be careful with Hidden
> > properties, but I think the WiX documentation is right - it only hides
> it from being written to the log.
> >
> > I didn't see anything in your POC that removed the "shared" variables
> > from the state file.
> >
> > I'm suggesting that "shared" is unnecessary, and that all Persisted="yes"
> > variables should be stored in the registry instead of the state file.
> >
> > On Wed, Jul 29, 2020 at 11:07 AM Hoover, Jacob
> > <Jacob.Hoover at greenheck.com
> > >
> > wrote:
> >
> > > I was trying to find a happy medium.  As the registry isn't a "secure"
> > > location, I was envisioning that it would be limited use so the
> > > author could explicitly define what they wanted to share. Going from
> > > memory, I don't think my POC implementation stores in both locations.
> > >
> > >
> > >
> > > Are you suggesting of eliminating local storage of variables and
> > > place them all in the registry?
> > >
> > >
> > >
> > > I'll work on a WIP as soon as I can garner enough feedback to at
> > > least ensure I am not totally off base.
> > >
> > >
> > >
> > > *From:* wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] *On
> > > Behalf Of *Sean Hall via wix-devs
> > > *Sent:* Tuesday, July 28, 2020 6:46 PM
> > > *To:* WiX Toolset Developer Mailing List
> > > <wix-devs at lists.wixtoolset.org>
> > > *Cc:* Sean Hall <r.sean.hall at gmail.com>
> > > *Subject:* Re: [wix-devs] WIXBUG3704 - Allow access to persisted
> > > variables from related bundles
> > >
> > >
> > >
> > > I think it's a good idea to persist the variables in the registry. I
> > > think there should be a single source of truth so I don't think they
> > > should also be persisted to the state file.
> > >
> > > I'm having trouble coming up with a use case for persisting a
> > > variable for the bundle but not for related bundles. Why shouldn't
> > > all persisted variables be "shared"?
> > >
> > > Please write a WIP.
> > >
> > > On Fri, Jul 24, 2020 at 10:14 AM Hoover, Jacob via wix-devs <
> > > wix-devs at lists.wixtoolset.org> wrote:
> > >
> > > > https://github.com/wixtoolset/issues/issues/3704
> > > >
> > > > I haven't done my searching yet, but this is related to some work
> > > > I had done internally. My thought was instead of allowing access
> > > > to persisted variables, to allow for "shared" variables which
> > > > would be written to the registry. In addition to not needing to be
> > > > concerned with format/version and/or invoking the other bundle to
> > > > ask it for data, we could simply
> > > allow
> > > > for shared variables to be accessed via the registry.
> > > >
> > > > I believe this was my rough in of the POC:
> > > >
> > > https://github.com/wixtoolset/wix3/compare/develop...jchoover:WIXFEA
> > > T3
> > > 704
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > Jacob
> > > >
> > > > __________________________________________________________________
> > > > __ WiX Toolset Developer Mailing List provided by FireGiant
> > > > http://www.firegiant.com/
> > > >
> > > ____________________________________________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant
> > > http://www.firegiant.com/
> > >
> > > NOTE: This email was received from an external source. Please use
> > > caution when opening links or attachments in the message.
> > >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>