Syncthing Windows Installer

:+1: Yes, sounds good.

I’m not sure how to do that using Inno Setup. I’d never created an installer before using this software, this is the first time. Just referred to their documentation all the way through haha

I don’t have it anywhere other than my machine, I’ll happily put it into a repository that you set up.

https://github.com/syncthing/winstaller - you should have an admin invitation in the mail. We can rename the repo if you like, it was the first thing that popped into my head. :slight_smile:

IDK if the author wants me to post here, but as it’s public domain I guess it’ll be fine.

You guys should check out SyncTrayzor, same as OP but but more “feature packed” (amongst others it has an Installer, “instant file watcher” built-in, close/minimize to tray etc.) and it’s for Windows: GitHub - canton7/SyncTrayzor: Windows tray utility / filesystem watcher / launcher for Syncthing

He has a few releases dished out already, check the release tab :slight_smile:

Been using it since 1.0 and after a few initial bug fixes it’s now very stable and I use it as a daily driver for my Syncthing needs on Windows

IMHO SyncTrayzor is what Syncthing should be shiped as on Windows by default (my 2 cents) :wink:

I’ve just been checking that forum post out, looks very good not too sure on the name but I do agree from the screenshots I’ve seen, it is what Syncthing should be shipped as for all OSes not just Windows but this is a start.

@AudriusButkevicius @calmh do you still want me to update that repo or would you rather have talks with @canton7 to see if it can be renamed to simply “Syncthing” and made part of the automated builds?

This is exactly what I am looking for, if this happened I would complete my transition from BTSync to ST.

I guess if @canton7 adds service control, his thing becomes superior to nssm + SyncthingTray? In which case perhaps we should offer that as the default thing for Windows.

Heh, they say the 2 hardest problems in computer science are cache invalidation, naming things, and off-by-one errors. Naming things is the bit I suck most at. You can tell it was never meant to become “official” anyway! :stuck_out_tongue: I’m happy to re-brand if the community deems that the most sensible approach, but I have reservations about using the ‘Syncthing’ name: that would cause undue confusion. Saying “Syncthing is a windows host for Syncthing” in a clear way is not something I want to attempt!

I’ve replied to your post in the SyncTrayzor thread:

Service vs start-on-login discussion moved to:

Thanks for making an installer. It worked perfectly on Windows 7 64 bit, Server 2012 R2 & Server Essentials 2012 R2.

Assuming it evolves from here (once service vs start on login is hammered out), one thing that is needed is to add the TCP port 22000 Windows firewall exception automatically.

Good point. Using a tray icon causes windows to (by default) prompt for a firewall exemption, at least on my home machines. Once you start getting into group policy, and services, etc, that’s going to become a trickier topic.

Well done . This project is really picking up some developer momentum. That’s really awesome to see.

I’d be happy to load up some EC2 instances and test it there. I’ll be able to test on Windows Server 2003 R2, 2008, 2008 R2, 2012, and 2012 R2.

Just let me know if there’s any formal acceptance criteria, or any requests for what OS it needs to be tested on. I have ISOs for every version of Windows going back to like Windows ME… I can load em up pretty quick in EC2 or VMware.

  • seems to be an old version
  • clciking on add peripheral does not do anything
  • it takes ages to connect to the localhost:8080

SyncTrayzor and Syncthing-GTK are linked from the Syncthing home page. They’re both mature, stable downloads with large numbers of users. I’m not sure I’d call them DIY…

Edit: @Curtis_Newton completely reworded the post I responded to, so this is no longer relevant.

I was talking about this very contribution

Ah, I see you’ve completely reworded the post I responded to.

Yes, this project hasn’t been touched for a year, and I don’t believe it’s even listed on the Community Contributions docs page.

Based on this idea of the Syncthing Windows Installer, I create a project on github called “Syncthing Light”.

Syncthing Light is a simple package installer for install and runs Syncthing as Windows Service (without tray utility - runs hidden).

If I may suggest a small change to your installer, especially since it’s being used by people that are less technically adept:

The SYSTEM account has elevated access to just about everything, and should not be used in this way. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms684190(v=vs.85).aspx for more info:

Most services do not need such a high privilege level. If your service does not need these privileges, and it is not an interactive service, consider using the LocalService account or the NetworkService account. For more information, see Service Security and Access Rights.

Syncthing can run perfectly fine under the LocalService account (NT AUTHORITY\LOCAL SERVICE) which is much better suited to it. It’s profile folder will be placed under C:\Windows\ServiceProfiles\LocalService\AppData\Local\Syncthing\ and will not be accessible by non-elevated accounts, which enhances the security of the private keys present in the profile folder. I’m running it this way myself, also with NSSM, and it works fine.

Kudos for creating the installer!

The problem is slightly more complex, and stems from two facts:

  1. Syncthing needs to be able to read and write the files it is synchronizing.
  2. By default, Syncthing can be configured by any user on the local machine.

These mean that, by default, any user on the local machine has access to any file which the user running Syncthing has access to.

If Syncthing is running as SYSTEM, then any user on the machine (including malware which hasn’t yet got administrative rights) can access virtually any file on the filesystem. That’s basically a rootkit. This is bad.

If Syncthing is running as LOCAL SERVICE, then by default it won’t have access to any files. Giving it access to files gives access to any process running as LOCAL SERVICE. This is bad. LOCAL SERVICE is meant to be a very restricted account.

Also remember that files created by Syncthing will be owned by the user Syncthing is running as. Having your files owned by a system or service account may or may not cause issues for you.

The only sensible thing to do when running Syncthing as a service is to run it as the user whose files you want to synchronize. This obviously makes the setup process a bit more complex, and makes multi-user setup a bit harder.

At the end of the day, starting Syncthing on login is a much more safe and user-friendly approach, particularly for new users. This is what all the major wrappers do.

All of this is explained in the docs, and there’s also this thread which is linked just a little further up in this thread.

(Setting a GUI password mitigates some of the issues listed above to a degree. However, 1) You’re now relying on there being no undiscovered vulnerabilities in Syncthing, 2) This isn’t particularly newbie-friendly, and 3) I saw no mention of the very pressing need to do this in @maxwelleite’s project instructions).

1 Like