Cannot create firewall rule as it keeps installing to a different folder.

[WictorWictor]

Hello,
I got an error in MSFS that said GSX needed to update. I keep giving GSX permission through the firewall, but it keeps failing. Seems the path is something like this:

\appdata\local\temp\is-ejrvl.tmp\couatl_updater.tmp

The "is-ejrvl.tmp" part changes on every installer attempt though, for some reason, which makes it impossible to create a windows firewall rule. It also seems that I cannot place a wild card * instead of it either, to create the firewall rule.

Disabling the firewall rule is a huge risk I would rather not go with. I noticed a mention of offline installer. Is that still available by any chance?

[virtuali]

A firewall is normally used to allow or disallow a specific application to accept or not incoming/outgoing network connection, so it wouldn't affect something that needs to write to a file.

Instead, the problem is likely the antivirus that, having mistakenly flagged the updater as a threat, is preventing it to write files into the default windows %TEMP% folder. The solution should adding the WHOLE Addon Manager folder to the antivirus EXCLUSIONS.

[WictorWictor]

so it wouldn't affect something that needs to write to a file.

Take a look at the screenshot:



Each program that needs internet pops up a notif like this in many firewall programs similar to the one I am using. You then either block it or give it permission. Doesn't work if the file is always in another spot, as it seems to be in this case.

Why does it need to go into a different folder each time?

[virtuali]

Each program that needs internet pops up a notif like this in many firewall programs similar to the one I am using. You then either block it or give it permission. Doesn't work if the file is always in another spot, as it seems to be in this case.

Why does it need to go into a different folder each time?

The problem is your firewall is just behaving wrong and, I'm not even sure the firewall is the cause, maybe it's because the antivirus blocked it first.

What you are looking at, is NOT our program in the act of working: is the STANDARD installation routine that is uncompressing itself in the Windows temporary folder BEFORE it even started, this is a completely normal practice, and each and every program that has an installer works that way: it ask Windows for a random folder name in the %TEMP% folder so it's entirely normal is always different, and it's not even something we coded ourselves, it's how each and every installer works.

The real mistake of your firewall or antivirus, is that is trying to block something that is hasn't even completed the installation, and is installing the same way as any other product: first by uncompressing itself in the Windows %TEMP% folder, and then copying itself into its final destination. If you try any installer of any product, it will be very similar, the issue is, your firewall or antivirus shouldn't not block anything yet.

[Copper]

My firewall (Windows firewall with restrictive rules) does the same by the way.
When running the Installer, I always need to first allow unknown programs for a short time, otherwise the initial connection attempt will be blocked until I confirm it and the FSDT Installer doesn't retry.

It has nothing to do with antivirus btw. It's just that the path of the program that tries to connect isn't static.

[virtuali]

It has nothing to do with antivirus btw. It's just that the path of the program that tries to connect isn't static.

But since it's completely normal the temporary location to decompress the installer files is always different, and every installer works the same, and it's not even something we control or coded, it goes without saying the firewall logic in this case is wrong or, possibly, just too restrictive.

I'm using the Windows Defender Firewall too, and I don't see any of that using the Default settings. You just can't change the firewall settings to be more restrictive than the default without expecting some kind of adverse effect on something, if there weren't any issues, it would have been set to be more restrictive by default.

I'll see if there's a way to change the installer ( we use Inno Setup ) to always use a fixed location for the initial decompress, it doesn't seem possible ATM.

[Copper]

Please simply add a "retry" prompt if the initial internet connection fails. That's what basically all installers do if they encounter a connection issue - to show a "Retry / Abort" dialog to the user to make sure that setting required permissions can be done without the need of restarting the installer (which then again creates a different path).

The variable path isn't really the issue. The handling of a failed connection is.

[virtuali]

The variable path isn't really the issue. The handling of a failed connection is.

Of course the variable path is not the issue, that's exactly what I've said, the real issue is the firewall behavior being too restrictive and even we changed it to allow to retry the download only to give a chance to create a new firewall rule, it's a messy solution, ending up with a new different firewall rule each time you ever ran the updater.

[Copper]

the real issue is the firewall behavior being too restrictive and even we changed it to allow to retry the download only to let you create a new firewall rule, it's a messy solution, ending up with a new different firewall rule each time you ever ran the updater.

Let that be my issue then if I have "duplicated" rules for the different paths.
The real issue is that your installer simply quits after one login attempt which is not how most installers work.

[virtuali]

Let that be my issue then if I have "duplicated" rules for the different paths.

No, because of those multiple exceptions might have side effects we might not anticipate now so, "your" issue might possibly become "our" support issue.

The real issue is that your installer simply quits after one login attempt which is not how most installers work.

It doesn't. When it downloads the 2nd part, it tries several times, with a half-second between each try, until it gives up after a certain number of tries.

The reason why there isn't a dialog, is that sometimes it needs a couple of tries even if the firewall doesn't interfere, and a dialog box with a "Retry" option would then annoy *everybody*, not just those with unreasonably restrictive firewall rules that are not default.

We might add a dialog if all tries failed, that's possible. I remind you the updater has been like this for years, and nobody ever reported such problem before.

[WictorWictor]

I am a software engineer with 20 years of experience. Please don't assume that I don't know what I'm talking about.

You do realize that I have used this firewall with many other programs, right? Firefox popped the same notification when it wanted access, I said yes, and it worked without issues. The problem is WITH YOUR SOFTWARE.

Why are you avoiding my question? Why is your installer and updater using a different folder each time? This is NOT standard behavior.

[WictorWictor]

the real issue is the firewall behavior being too restrictive and even we changed it to allow to retry the download only to let you create a new firewall rule, it's a messy solution, ending up with a new different firewall rule each time you ever ran the updater.

Let that be my issue then if I have "duplicated" rules for the different paths.
The real issue is that your installer simply quits after one login attempt which is not how most installers work.

Thank you so much for chiming in. I appreciate knowing that I am not the only one concerned about security issues and trying to use a firewall properly. It's frustrating explaining here how GSX is not working right, as if they don't use software from other companies as well, and can easily reproduce this. Guessing their dev environment doesn't use firewalls...

[WictorWictor]

The variable path isn't really the issue. The handling of a failed connection is.

Of course the variable path is not the issue, that's exactly what I've said, the real issue is the firewall behavior being too restrictive and even we changed it to allow to retry the download only to give a chance to create a new firewall rule, it's a messy solution, ending up with a new different firewall rule each time you ever ran the updater.

The path IS the issue, I don't even understand how this is a point of debate. Firewall needs a valid path to set up it's rule. There is no reason your software should be going to a different folder each time. Here is the screenshot from the firewall, that clearly shows why allowing a connection will not work, as it uses a different path next time. This example shows 3 attempts to run the updater, with 3 different paths.



Just to be clear, there is nothing wrong with using a temp file. The problem is using a temp folder.

[virtuali]

I am a software engineer with 20 years of experience. Please don't assume that I don't know what I'm talking about.

The thing is, by saying this:

Why is your installer and updater using a different folder each time? This is NOT standard behavior.

Doesn't seem to confirm your previous statement. It's common knowledge that most installers use this exact method.

Just to be clear, there is nothing wrong with using a temp file. The problem is using a temp folder.

I guess that a software engineer must have heard of the open-source INNO SETUP ? That's what we use to do installers, and this is used by THOUSANDS of software products, and every single one of them WILL use a different sub-folder inside the %TEMP% folder, at least all the thousands of products that have their installer made with Inno Setup, which I think it's the most popular installer out there.

But of course, before I say something, I always check my facts first, so I posted a question on Inno Setup support groups, asking if it was possible to CHANGE this behavior and use a different location for the initial decompress step which, again, it's NOTHING WE CODED:

https://groups.google.com/g/innosetup/c/_1_xHxfWjsE/m/1kKSeSu3EQAJ?utm_medium=email&utm_source=footer

Guess the answers:

Firewalls are not typically configured to prevent outgoing connections, which is what that is. So usually no firewall changes are needed.

There is not currently any option for that.

So, checking the facts results that:

- One of the most popular install routines, which is used by thousands of products out there, ALWAYS decompress and execute itself from a random sub-folder in the %TEMP% folder, so much for your statement it's "not standard behavior", guess you haven't paid much attention how installers really work.

- This behavior can't be changed

- During the very long life of one of the most popular install routines ( it first came out in 1997! ), NOBODY ever felt the need to add an option to change that behavior.

[Copper]

Firewalls are not typically configured to prevent outgoing connections

That itself is SO far from reality that I see no common ground for further discussion.

As so often, we'll end up using workarounds.
The way you talk about your customers on the other board is kind of discouraging btw.