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

[Rob Mensching]

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