[wix-devs] #5658 - Burn problem with AV

[Blair Murri]

I'm not a big fan of custom error codes, but I don't care enough to say no to this one, either.

I don't have any boxes with the AV's mentioned, nor do I have enough free disk space to spin a new VM up for testing purposes. I'm willing to code up what Sean is describing, but I'll just be throwing it over the fence.

My only remaining question is: what should the timeout value be (to give the human user time to respond to the AV and for the AV to then disengage it's suppression of communication). Off the top of my head I'd recommend 30 seconds, but I'm not a UX expert.

Thoughts?

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> on behalf of Bob Arnson via wix-devs <wix-devs at lists.wixtoolset.org>
Sent: Monday, December 17, 2018 7:29:25 PM
To: WiX Toolset Developer Mailing List
Cc: Bob Arnson
Subject: Re: [wix-devs] #5658 - Burn problem with AV

I have no context, haven't reviewed the issue/PR, etc., but I wholeheartedly endorse E_SUSPECTED_AV_MEDDLING solely for its name.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Monday, 17 December, 2018 10:14
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] #5658 - Burn problem with AV

So it sounds like we want to try adding a retry first and see how it goes?

The pull request right now is calling itself before cleaning up, which is bad. My current idea is to make that elevate function return a custom error code, something like E_SUSPECTED_AV_MEDDLING. Then make Apply auto retry once.

On Mon, Dec 17, 2018 at 1:36 AM Blair Murri <osito at live.com> wrote:

> I think the point was that the AVs are blocking the second hop while
> asking the user how to proceed. Once the user responds granting
> access, the code with the retry logic works, if I'm reading the
> responses to the issue correctly.
>
> We've never released any version containing the retry logic. We
> haven't added the retry logic to any branch. No one has even critiqued
> pull request containing the proposed retry logic (which includes me,
> as it's not clear to me that the proposed solution is optimal, but I
> truly haven't stopped to think about it, either).
>
> I don't think disabling the clean room is the right solution, unless
> someone with something based on the proposed solution isn't working or
> a good argument is made that the user can't work with an AV's dialog
> asking to allow a program they launched to proceed.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* wix-devs <wix-devs-bounces at lists.wixtoolset.org> on behalf of
> Sean Hall via wix-devs <wix-devs at lists.wixtoolset.org>
> *Sent:* Thursday, December 13, 2018 10:28:08 AM
> *To:* WiX Toolset Developer Mailing List
> *Cc:* Sean Hall
> *Subject:* Re: [wix-devs] #5658 - Burn problem with AV
>
> The whole thing - because one person said their bundle built with v3.9
> worked fine, and another implying that the issues started when using v3.11.
> It's possible the companies are allowing one hop
> (unelevated->elevated) but not two (unelevated->clean room->elevated).
>
> On Thu, Dec 13, 2018 at 12:20 PM Rob Mensching <rob at firegiant.com> wrote:
>
> > The initial report in that issue is about the elevated Burn not
> > about the clean room. What part of the issue would be helped by not
> > doing clean
> room?
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Sean Hall via wix-devs
> > Sent: Sunday, December 9, 2018 3:02 PM
> > To: WiX Toolset Developer Mailing List
> > <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: [wix-devs] #5658 - Burn problem with AV
> >
> > For https://github.com/wixtoolset/issues/issues/5658, I'm not
> > convinced that we are going to be able to find a foolproof
> > workaround for these problematic AV's. Would it be acceptable to add
> > a /disablecleanroom
> switch,
> > disable clean room if running in a specially name folder, or
> > something
> else
> > like that instead? I would think that would be ok security-wise
> > since if
> a
> > malicious entity can run our bundle with that switch they already
> > have
> code
> > execution.
> >
> > Also, have we submitted the latest v3.11 to each of the vendors in
> > the issue - Avast, AVG, PC Matic SuperShield?
> > ____________________________________________________________________
> > 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/