Syncthing Windows Setup 1.23.7

Syncthing Windows Setup is a lightweight yet full-featured Windows installer.

Documentation and download: GitHub - Bill-Stewart/SyncthingWindowsSetup: Syncthing Windows Setup

Changes from previous releases:

  • Default new installation selection is per user (non administrative)

  • Relaying is disabled by default

The change to the relaying default is because of the persistence of anti-malware and security scan false-positives. If you use relaying, you will need to specify true in the config dialog when installing, or specify /relaysenabled=true on the installer’s command line. (See the documentation for details). You’ll only need to do this once, and the installer will remember it. Sorry for this change, but this is to reduce the number of false-positives and the number of nuisance issues I receive as a result of these.


I second this. While my syncthing-msi has everything enabled by default, I also ship a transformed version with the relay/global disco switches off to my friends and family for that reason it’s not needed and antivirus goes boom on it.

I would love to have some welcome popup in the Syncthing web ui which shortly explains relaying and then offers two big buttons to the user:

“I’m a network novice, assist me by turning relay on”

“I’m a network expert, turn off relay and I’ll figure myself out how to connect devices by IP:port”

… Some time ago, I also planned to do something similar in Syncthing Android. But the welcome slides are already a lot so I dropped the idea before users get angry clicking to the slides thinking the app will never “let them in”.


Please don’t bunch global discovery and relay in together, they have almost nothing to do with each other. While I can see why you’d want to disable relaying on a typically broken system (broken as in windows without tweaking), that’s definitely not the case for global discovery. That would be actively harmful to users and I’d not want any tool with “syncthing” in it’s name to do that. As I understand that’s the case here, i.e. “Windows Setup” still has global discovery enabled.

Microsoft isn’t really the one to blame here. Windows Defender doesn’t complain about Syncthing and its usage of relays. I can say this confidently as I’ve been using Syncthing with all connectivity options at default on a large number of systems that have Windows Defender enabled and I have never seen any warning from it in relation to Syncthing.

It’s the third party antivirus software vendors that seem to always have problems with relays.

We are getting off topic here (and I am entirely to blame for that :slight_smile: ), the point is that what seems to cause problems with relays all the time (false positives due to other services running on the same hosts), is not an issue with global discovery. Also global discovery is vital to connect, with or without relays.

Now I’ll induldge in some more off-topicness, as it’s a welcome opportunity for me to let off some steam as I am unfortunately exposed to Microsofts terrifying incompetence (well negligence, I am sure they could do better) since a while (again): What you say is likely true, but I still do think Microsoft is to blame (at least partially) for the state of their ecosystem, given their UX that normalizes behaviour that’s terrible for security (e.g. anything around software upgrades) and their behaviour in the face of real security issues (ignore until it can’t be ignored anymore, then downplay and promise a fix in half a year or so, unless the outcry gets large enough, then suddenly the fix can be provided within a day). All the while not changing anything to improve overall security, but trying to sell more snake oil - I mean breakage is good for business, more (paid) support opportunities. Companies are (or think they are) locked in to Microsoft anyway, so they don’t need to fear losing customers.

I’d say relays are vital too, especially today when most people carry around a phone or a laptop that they want to connect to the Internet and sync on the go. I’m just not a fan of disabling relays by default personally. It may possibly bring a lot of support requests from users that can’t sync their Android phones with their computers (which is already problematic enough with local discovery being broken).


I understand the concern about disabling relays as a default. The problem is that when sandbox malware analyzers install the package, Syncthing might make an outgoing TCP connection to a IP that’s shared with a “dangerous” service, and the installer gets flagged as malware. This is a false-positive, of course, but explaining this repeatedly to every anti-malware vendor every time a new installer gets released is tedious, to say the least.

I’m not deploying anything else than the defaults, but my syncthing-msi also targets private/enterprise environments where “no connections should be towards the internet”. The default of global+relay is enabled, but the admin can set a switch which my msi installer will honor to disable specific connection helpers. So, no “harm” intended here. Family and friends don’t need the global+relay features as I care about those nodes and static IP config. I’ve disabled those features manually in the past and now the installer takes care of it (reading the optional mst file).

Defaults in my msi setup are:

<Property Id='globalAnnounceEnabled' Value='true' />
<Property Id='localAnnounceEnabled' Value='true' />
<Property Id='natEnabled' Value='true' />
<Property Id='relaysEnabled' Value='true' />

So I’ve understood you wouldn’t like to see a chooser in the Android app where one option is to disable “community hosted services” like global+relay. Okay.

Options are fine, I wouldn’t want to by default/silently disable them.

Also perfectly clear that there are specific circumstances where such a config makes sense, just talking about general purpose use here.

1 Like

Security softwares continue to complain about this installer, primarily because it contains the nssm executable. It’s basically a “knee jerk” reaction (it seems that ignorance abounds in the security space). Because of this silliness, the next release of the installer will use shawl to run the service instead of nssm, in the hopes that this will reduce the number of false positives.

I’d say that changing defaults we ship in general is a bad idea.

Sure, it might make sense to you when you understand the concepts etc, less false positives etc but for a novice it will probably end up installing software in a way that generally does not work.

The support of those not working installations will fall on us, not you, so I would prefer if we stuck with the defaults that we set and know generally delivers a working installation.

If we want the experience to those features be better, i.e., explaining the side-effects etc, warn about antivirus, make it opt in etc, we should work on that, instead shipping software which will generally not work for some users.

1 Like

Unfortunately, the only sensible strategy is to succumb to the security theatre of the Windows world and sign the installer, if you haven’t already done so.

But that’s a lot of hoops to jump through, and even more money to waste by paying the CA mafia.

The Syncthing Foundation could theoretically sign it, but that would mean handing over the project so that the maintainers could faithfully guarantee that we’re not signing potential malware.

That’s a lot of work and I doubt that the project members want to dive deep into Windows installer territory to vouch for it.

I don’t have a code-signing certificate, and I’m not going to buy one. I would be more than happy for the Syncthing maintainers to take it over, but I doubt they have the resources/desire to do that.