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

[Hoover, Jacob]

Interesting.

If I only do this in 4, would you think any effort would need to be done to try to farm off 3x state data, or can we just say from 4 going forward it’s in the registry?

From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, July 29, 2020 12: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

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<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)<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<mailto: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<mailto:wix-devs at lists.wixtoolset.org>>
> *Cc:* Sean Hall <r.sean.hall at gmail.com<mailto: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<mailto:wix-devs at lists.wixtoolset.org>> wrote:
>
> > https://github.com/wixtoolset/issues/issues/3704<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:WIXFEAT3704<https://github.com/wixtoolset/wix3/compare/develop...jchoover:WIXFEAT3704>
> >
> > Thoughts?
> >
> > Thanks,
> > Jacob
> >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/<http://www.firegiant.com>
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/<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/<http://www.firegiant.com/>
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.