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

Wed Jul 8 05:52:18 PDT 2020

I created a WIP for this at
https://wixtoolset.org/development/wips/4822-in-progress-arp-entry/. It
didn't seem to me like we had agreed about anything yet.

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

> (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/
>>>
>>