Auto-update "breaks" managed installations

[m4rtelli]

Using a supported version? - Yes :)

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Good day. I am managing a controlled deployment of Signal Desktop for Windows. Installation is performed under System Context with the standard Signal installer executable being called with these switches "/S /D=C:\Program Files\Signal".

Installation is fine and the Signal.exe app launches without issue afterwards. However, with automatic updates enabled, I am seeing that the update actually installs itself under the current user (%localappdata%\Programs\signal-desktop) which is creating a few problems:

1. A second entry for Signal is now displayed in Add/remove programs as well as second desktop/start menu shortcuts. Basically treating it as a secondary installation.
2. The existing version no longer works and throws a database error on startup.

Please advise as to what could be the possible cause here and also, is the automatic update of the application supported when the initial installation path is changed? Thanks a bunch!

Steps to reproduce

1. Install Signal 7.71 using /S /D= switches and change the default path
2. Allow an automatic update afterwards to v7.72

Expected result

Expecting automatic update to just install into the existing directory path

Actual result

Update mechanism is creating a second installation of Signal.

Screenshots

No response

Signal version

7.72 (current installed version is 7.71)

Operating system

Windows 11

Version of Signal on your phone

No response

Link to debug log

No response

[indutny-signal]

Thank you for this report. We'll take a look! I think it should be possible to disable the updates when running from a custom path, but we will make sure to consider all possible alternatives.

[m4rtelli]

Thank you for this report. We'll take a look! I think it should be possible to disable the updates when running from a custom path, but we will make sure to consider all possible alternatives.

Thank you so much for the response. I'm pretty sure that I can disable auto-updates by adding an entry to the hosts file on the system. Ideally though, I'd like to have the application auto-update itself :)

[indutny-signal]

Ah, so if it'd pass along that custom folder to the installer it wouldn't interfere with your configuration?

[m4rtelli]

Ah, so if it'd pass along that custom folder to the installer it wouldn't interfere with your configuration?

I believe so. Does the automatic update check the Registry for the installation path or is it hardcoded to just assume it's in %localappdata%?

[indutny-signal]

@m4rtelli I think it is hard-coded, but I'll have to double-check since we use the installer from electron-builder npm package.

[m4rtelli]

@m4rtelli I think it is hard-coded, but I'll have to double-check since we use the installer from electron-builder npm package.

Alrighty, thanks. Ideally, if the installation supports a /D switch to change the initial install dir then the auto-update should respect that. I appreciate you responding so quickly to have a look. That is fabulous support.

[m4rtelli]

Hi. Just checking if there's an update on this yet? Thanks.

Two things to add :)

1. If you have a way that I may block the update, please let me know (I tried adding "127.0.0.1 updates.signal.org" to the HOSTS file, but that didn't prevent the update).
2. If you will be implementing a fix.

@indutny-signal :)

[m4rtelli]

Hi @indutny-signal - Hope this message finds you well. Is there any update for us here? This unfortunately is a production issue for our users. Thanks!

[indutny-signal]

@m4rtelli hi! Sorry for the delay. Could you check Computer\HKEY_CURRENT_USER\Software\7d96caee-06e6-597c-9f2f-c7bb2e0948b4's InstallLocation key in the registry?

I think this is the value that is used for determining the target directory for the update and my guess is that your users don't actually have it set. Setting it for everyone might be a simple workaround!

[m4rtelli]

@m4rtelli hi! Sorry for the delay. Could you check Computer\HKEY_CURRENT_USER\Software\7d96caee-06e6-597c-9f2f-c7bb2e0948b4's InstallLocation key in the registry?

I think this is the value that is used for determining the target directory for the update and my guess is that your users don't actually have it set. Setting it for everyone might be a simple workaround!

Thanks for the response. Is it mandatory for the key to reside under Current User? We have this key added to Local Machine since the install location is Program Files.

[indutny-signal]

Technically not, but this is how it is implemented in electron-builder https://github.com/electron-userland/electron-builder/blob/e5f5799fbb193a7a8700fcaaf1ab9e79c9c694ce/packages/app-builder-lib/templates/nsis/multiUser.nsh#L26 so there is not much choice aside from asking electron-builder to read it from other keys too.

[m4rtelli]

Technically not, but this is how it is implemented in electron-builder https://github.com/electron-userland/electron-builder/blob/e5f5799fbb193a7a8700fcaaf1ab9e79c9c694ce/packages/app-builder-lib/templates/nsis/multiUser.nsh#L26 so there is not much choice aside from asking electron-builder to read it from other keys too.

Ok so from that line it does indeed appear that the requirement is to have the Keys under HKCU instead of HKLM. I'm going to make the change to the scripts in our package to target HKCU as it seems that should "fix" the auto-update dilemma. It seems like an odd choice to allow the directory change, but have no flexibility on the Registry.

I'm hoping that once I implement the change, the auto-update should no longer create a second installation on the disk. If I absolutely had to, what is the recommended way to block the auto-update?

[indutny-signal]

Ok so from that line it does indeed appear that the requirement is to have the Keys under HKCU instead of HKLM. I'm going to make the change to the scripts in our package to target HKCU as it seems that should "fix" the auto-update dilemma. It seems like an odd choice to allow the directory change, but have no flexibility on the Registry.

I hope it works out!

I'm hoping that once I implement the change, the auto-update should no longer create a second installation on the disk. If I absolutely had to, what is the recommended way to block the auto-update?

If it doesn't work - let's try to figure out what would make it work first, and if that fails discuss the alternatives! I'm really hopeful that it'd work, though!

[m4rtelli]

Ok so from that line it does indeed appear that the requirement is to have the Keys under HKCU instead of HKLM. I'm going to make the change to the scripts in our package to target HKCU as it seems that should "fix" the auto-update dilemma. It seems like an odd choice to allow the directory change, but have no flexibility on the Registry.

I hope it works out!

I'm hoping that once I implement the change, the auto-update should no longer create a second installation on the disk. If I absolutely had to, what is the recommended way to block the auto-update?

If it doesn't work - let's try to figure out what would make it work first, and if that fails discuss the alternatives! I'm really hopeful that it'd work, though!

Sounds good. Thanks again for your time. I'll circle back once I've implemented the change.

[indutny-signal]

@m4rtelli we published a new release a couple of days ago so I thought I circle back and see if the update process worked for you. 🤗