Avasts blocks install, even after you tell it to trust installer file.

[tvleavitt]

How can the problem be recreated?

Download latest pre-release, attempt to install it. Avast pops up a warning message. Attempt to bypass the warning message by saying you trust the file, and installation fails to start with a operating system level "permission denied" error. Running as Administrator does not help. Running install from a cmd session run as Administrator does not help.

The only solution that enables the installer to run is to temporarily disable the Avast "shields" interface entirely. This may be an Avast bug, but will affect any attempt to install if Avast is present (17% of the Windows anti-virus market). Not sure how best to deal with this, the workaround is simple enough, but the failure of Avast to let you run the program even after you tell it that you trust it is going to be a real headscratcher for a lot of people, I suspect. I believe there's a way to whitelist the file, and especially for any stable release, this would be of benefit.

What is an expected fix?

For the prerelease versions, a README or FAQ explaining that if you have Avast for Windows installed (not sure what would happen on OS X), you need to temporarily turn it off completely in order to install would likely be helpful. Encouraging people to read it before downloading and running the installer would also make sense.

Maybe make a link under "Download Prerelease" with a brief explanation of what a pre-release is, how users can help with testing, and issues they may run into (such as save game incompatibility, etc.)?

Which Engine Version are you using?

(Optional) Additional information

[DanVanAtta]

@tvleavitt It sounds like 1.9 did not suffer this problem, is that the true? I'm a bit curious what might have changed to such that Avast is not happy. The two most likely suspects for that are we upgraded install4j from v7 to v8, and we are bundling a JDK now always. Regardless that delta may be immaterial.

Doing an automated FTP to Avast would be great, need to weigh a few things:

• complexity
  • do we really want to do that multiple times a day?
  • will it introduce potential build indeterminism
• limitations, it looks like the web page upload from has a 60MB limit, if such a limit exists we are going to be potentially out of luck
• if we are releasing a latest only a few times a month or a few times a quarter, perhaps uploading by hand will be sufficient, in which case this becomes a task to update release process notes to do this and we add a 2.0 release task to do this.

[tvleavitt]

Dan,

I suspect that what happens here is that Avast's system hasn't been trained to recognize the specific file / installer; I saw a message this a.m. saying that Avast had finished inspecting the file and found no problems. I'm betting that this prerelease may not trigger the problem again, but the next one will. I suspect what happened with 1.9 is that you released it, a few people ran into this, but the problem went away after a short period and thus most people didn't encounter it (when was that?). Contrawise, there will no doubt be a rush to install 2.x whenever it is officially released, probably more so than with the 1.9 stable build, and thus I'd expect more people to run into it.

I'd say that, so long as we document this for testers, it shouldn't be an issue for pre-releases, but that we'd be advised to pre-seed Avast (essentially) with a working copy of the binary to avoid this scenario being repeated when the / a production release occurs.

Thomas

On Wed, Apr 22, 2020 at 4:48 PM Dan Van Atta notifications@github.com wrote:

@tvleavitt https://github.com/tvleavitt It sounds like 1.9 did not suffer this problem, is that the true? I'm a bit curious what might have changed to such that Avast is not happy. The two most likely suspects for that are we upgraded install4j from v7 to v8, and we are bundling a JDK now always. Regardless that delta may be immaterial.

Doing an automated FTP to Avast would be great, need to weigh a few things:

• complexity
  • do we really want to do that multiple times a day?
  • will it introduce potential build indeterminism
• limitations, it looks like the web page upload from has a 60MB limit, if such a limit exists we are going to be potentially out of luck
• if we are releasing a latest only a few times a month or a few times a quarter, perhaps uploading by hand will be sufficient, in which case this becomes a task to update release process notes to do this and we add a 2.0 release task to do this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6306#issuecomment-618096323, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HAOUGPINKG5YCRJEU33RN5627ANCNFSM4MNXCBYA .

-- Thomas Leavitt Internet enabled since 1990

[tvleavitt]

Downloaded the latest pre-release, and Avast was triggered again (same bogus demand for admin privs, didn't capture that, but captured the Avast pop ups).

[tvleavitt]

Suggest that this might be the equivalent of actually uploading the file to Avast via FTP for whitelisting.

[tvleavitt]

Here's a full sequence of captures from the latest pre-release, including Avast approving it eventually, and the OS level Windows dialogue that pops up. Note: Windows Defender also tags this (even before Avast, though Avast appears to pre-empt it at some point). Filing a separate issue with that.

First Avast! pop-up notification:

Second Avast! pop-up (after re-running installer):

OS level notification:

Message / notification inside Avast! application:

Message after Avast! determines file is not dangerous:

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.