[wix-devs] 4822 - Delay ARP registration in Bundles until a non-permanent package is installed

Wed Jul 1 15:47:53 PDT 2020

(Needed to send to the list)

On Thu, Jul 2, 2020 at 8:38 AM Sean Hall <r.sean.hall at gmail.com> wrote:

> I think we should go with the "In-progress ARP name" then. Trying to get
> the engine to clean up when the engine is shutting down is always going to
> have problems. The BA may not be calling the engine's Quit method and could
> be shutting down the process itself. The process may crash or the whole
> system may lose power. But no, the Burn engine does not have to help. An
> intelligent BA can realize that no non-permanent packages are installed and
> silently do an uninstall before calling the engine's Quit method, this is
> the current workaround in v3 (although there's still the misleading ARP
> entry if user checks before they finish interacting with the Bundle after
> reboot).
>
> By calling it "In-progress" are you suggesting that it is a temporary name
> that is used throughout Apply, or are we going with my proposal of using it
> until a non-permanent package is installed?
>
> This seems to be too simple to create a new element for it, so it would
> have to be another attribute on Bundle I think.
>
> On Thu, Jul 2, 2020 at 3:38 AM Rob Mensching <rob at firegiant.com> wrote:
>
>> 1. The idea of an "In-progress ARP name" is interesting independent of
>> all of this. If named well, it could help explain the ARP entry when the
>> bundle exited unexpected.
>>
>> 2. The "worst case" user scenario IMHO is the user that started the
>> product install, restarted due to .NET Framework pre-req then decides to
>> cancel the product install. That is the case where I can clearly see why
>> people don't want any part of the product remaining.
>>
>> 3. I'm not sure there is much Burn can do to protect itself from a poorly
>> designed BA. We purposefully give significant control to the BA. At the
>> same time, it's ideal if Burn generally does the right thing when the BA
>> doesn't override behavior (i.e. the Burn recommendations are right)
>>
>> That is why I wondered if an extra parameter passed in via RunOnce could
>> inform the engine that by default, if the BA exits without execution (or if
>> execution fails) the ARP entry and cache should be cleaned up as if this
>> was a "first time install" (even though pre-req(s) was(were) already
>> installed and required a restart).
>>
>> Correct me if I'm wrong as I thought the Burn engine would have to help
>> the BA in some way.
>>
>>
>> -----Original Message-----
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
>> Hall via wix-devs
>> Sent: Tuesday, June 30, 2020 7:25 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] 4822 - Delay ARP registration in Bundles until a
>> non-permanent package is installed
>>
>> I guess a different way to do this would be to add the ability to author
>> an alternative ARP DisplayName. So the normal one could be "My Bundle", and
>> the alternative one could be "My Bundle Prerequisites". Burn would use the
>> alternative DisplayName (if provided) when initially creating the ARP
>> entry, and then would update the ARP entry with the normal one once a
>> non-permanent package was installed.
>>
>> This way, there's still an ARP entry tied to the cached bundle. But the
>> user isn't led to believe the installation is complete because the
>> alternative ARP DisplayName should make it clear that the actual
>> application hasn't been installed yet.
>>
>> On Wed, Jul 1, 2020 at 9:26 AM Sean Hall <r.sean.hall at gmail.com> wrote:
>>
>> > This new design would only leave detritus on the computer if the BA
>> > doesn't clean up. So unless we start allowing Burn to do real work
>> > without involving the BA, adding command line parameters wouldn't
>> > help. Also remember that the ARP entry isn't supposed to exist, we
>> > should only be concerned about cleaning the cache.
>> >
>> > Making the elevated engine automatically clean up based on a
>> > command-line parameter is possible, assuming that Burn shuts down
>> > cleanly (so we're still relying on a well-behaved BA).
>> >
>> > On Wed, Jul 1, 2020 at 3:24 AM Bob Arnson via wix-devs <
>> > wix-devs at lists.wixtoolset.org> wrote:
>> >
>> >> +1
>> >>
>> >> -----Original Message-----
>> >> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
>> >> Rob Mensching via wix-devs
>> >> Sent: Tuesday, 30 June, 2020 13:23
>> >> To: WiX Toolset Developer Mailing List
>> >> <wix-devs at lists.wixtoolset.org>
>> >> Cc: Rob Mensching <rob at firegiant.com>
>> >> Subject: Re: [wix-devs] 4822 - Delay ARP registration in Bundles
>> >> until a non-permanent package is installed
>> >>
>> >> Would it help if there was an additional command-line argument
>> >> registered with RunOnce when all packages planned were permanent?
>> >>
>> >> Then post-restart the run-once'd elevated Bundle would know if the
>> >> cached bundle and ARP should be removed if no execution happens (and
>> >> possible modify planning so execution removes ARP entry on failure).
>> >>
>> >> Bob's "registry cleaners" comment comes down to the fact that we
>> >> really don't want to have a design that says, "Registry cleaners are
>> >> useful for cleaning up the cache because we made a design decision
>> >> that leaves behind detritus on your computer".
>> >>
>> >> -----Original Message-----
>> >> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
>> >> Sean Hall via wix-devs
>> >> Sent: Sunday, June 28, 2020 3:19 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] 4822 - Delay ARP registration in Bundles
>> >> until a non-permanent package is installed
>> >>
>> >> If it weren't for the reboot, then yes Burn could automatically
>> >> uncache at the end of Apply.
>> >>
>> >> In the reboot scenario, no. Burn would have to rely on the BA to
>> >> uncache if the user cancels. "Registry cleaners" are already
>> >> incorrectly blowing away Burn packages in the cache so I don't think
>> >> that makes a difference here.
>> >>
>> >> On Mon, Jun 29, 2020 at 8:00 AM Bob Arnson <bob at firegiant.com> wrote:
>> >>
>> >> > Could the bundle not trigger an uncache? If not, it's a nonstarter:
>> >> > Leaving cache behind is how "registry cleaners" start to
>> >> > legitimately target Burn and make everyone's life miserable.
>> >> >
>> >> > -----Original Message-----
>> >> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
>> >> > Sean Hall via wix-devs
>> >> > Sent: Sunday, 28 June, 2020 17:33
>> >> > 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] 4822 - Delay ARP registration in Bundles
>> >> > until a non-permanent package is installed
>> >> >
>> >> > No, it doesn't need to be registered in ARP for anything but
>> >> > allowing the user to remove the bundle from the cache. The bundle
>> >> > can be run from the RunOnce key after the reboot without having an
>> >> > ARP entry. But it does need to stay in the cache. For security, the
>> >> > RunOnce key must point to the cached bundle. There's no way to do
>> >> > automatic uncache in
>> >> this scenario.
>> >> >
>> >> > On Mon, Jun 29, 2020 at 6:39 AM Bob Arnson <bob at firegiant.com>
>> wrote:
>> >> >
>> >> > > It needs to register and be cached to restart on reboot, right?
>> >> > > If all packages are permanent and not cached, then automatic
>> >> > > unregiration/uncache seems reasonable.
>> >> > >
>> >> > > -----Original Message-----
>> >> > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf
>> >> > > Of Sean Hall via wix-devs
>> >> > > Sent: Sunday, 28 June, 2020 07:17
>> >> > > To: WiX Toolset Developer Mailing List
>> >> > > <wix-devs at lists.wixtoolset.org>
>> >> > > Cc: Sean Hall <r.sean.hall at gmail.com>
>> >> > > Subject: [wix-devs] 4822 - Delay ARP registration in Bundles
>> >> > > until a non-permanent package is installed
>> >> > >
>> >> > > I'm interested in implementing
>> >> > > https://github.com/wixtoolset/issues/issues/4822. This is the
>> >> > > hard scenario that needs to be solved:
>> >> > >
>> >> > > 1. User starts the per-machine bundle on a clean machine.
>> >> > > 2. The bundle has an MBA and needs to install the .NET Framework.
>> >> > > 3. The bundle caches itself into the package cache.
>> >> > > 4. The bundle registers in ARP.
>> >> > > 5. The bundle creates a RunOnce key.
>> >> > > 6. The bundle installs the permanent .NET package, which requires
>> >> > > a
>> >> > reboot.
>> >> > > 7. The bundle updates the RunOnce key to resume after the reboot.
>> >> > > 8. The user allows the prereq BA to reboot the machine.
>> >> > > 9. RunOnce starts the bundle elevated.
>> >> > >
>> >> > > Because RunOnce always starts the target program elevated, we
>> >> > > need to cache the bundle into the package cache (or other
>> >> > > protected area) to be secure.
>> >> > > In order to allow the user to clean up their machine, we are
>> >> > > registering in ARP to give them a way to clean the cache.
>> >> > >
>> >> > > If we want to implement this feature, I think we're going to have
>> >> > > to allow the possibility of the bundle being cached without an ARP
>> entry.
>> >> > > Either Burn removes the ARP registration somewhere between 6 and
>> >> > > 8, or it never registers in the first place (because all planned
>> >> > > packages are
>> >> > permanent).
>> >> > > Is this acceptable or is this feature not possible?
>> >> > > _________________________________________________________________
>> >> > > ___ 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/
>> >> ____________________________________________________________________
>> >> WiX Toolset Developer Mailing List provided by FireGiant
>> >> http://www.firegiant.com/
>> >>
>> >
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>