Syncthing Windows Setup is a lightweight yet full-featured Windows installer.
Documentation and download: GitHub - Bill-Stewart/SyncthingWindowsSetup: Syncthing Windows Setup
This version includes a bug fix that resolves an issue for automatic upgrades in administrative installations.
Note to users: If your security software flags the installer as malware, please submit it to your vendor as a false-positive.
Runs very well. If at some point the issue with the virus scanner is fixed, it will be perfect.
How can we support, what should we test?
As mentioned in the first post in this thread:
If your security software flags the installer as malware, please submit it to your vendor as a false-positive.
Done for the possible files. I add also to the exceptions, if possible.
In the follow case I got now a blockage, I cant handle as false-positive or exception
To solve this, I deactivate my scanner during the installation.
In my opinion your security software is far too aggressive. This is absolutely a false positive.
powershell.exe is a core Windows file that it definitely should not be blocking. (I sometimes wonder if security vendors who develop tools for Windows actually understand how Windows security works.)
I’m not so sure about that. Precisely because the powershell.exe is an elementary Windows application, its use is maybe to be announced if this is addressed via a script. If I open the powershell.exe manually, it opens and no messages like the above shown appear.
Well, finally I have no problem, during a installation I turn off the virus scanner for 10 minutes, I can leave that. This is how I have done so far. However, I have seen an issue on Github about installations on restricted computers and there it is a stroke of luck if a virus scanner can be switched off.
Finally, I have no idea to solve, but if I can help, please let me know.
The security software doesn’t seem to understand the principle that PowerShell is a program and not a security boundary.
All: As a courtesy to the community at large, I am submitting syncthing-1.21.0-setup.exe to the malware vendors as a false-positive. As of today, the false-positive rate has dropped by 11 from yesterday (yesterday, 25 engines detected it as malware, today it’s 14):
As a result of this sad and absurd situation, I’m not going to be releasing an updated installer for the new 1.22.0 release because this will generate a new executable and a new hash and a whole new round of false-positives. Fortunately the automatic upgrade facility built into Syncthing will address most use cases. If you’ve disabled automatic upgrading, all you have to do is stop Syncthing and replace the
syncthing.exe file with the new version.
Frankly, I would create the v1.22.0 anyway, because probably everyone knows the story with the false alarms and everyone deals with it in his own way. Furthermore, in my opinion, missing updates could also be interpreted to mean that the project is no longer being developed. If users then jump off because of this, that would be a great pity.
Our, especially my contributions to the false alarms, only refer to the fact that they are known and possibly contribute to the overall optimizations. That’s really all for me. I still use your excellent tool, after all I know how to handle it.
Once I get 1.21.0 approved by all of the vendors, I will have a precedent for getting future versions approved as well. Some of these vendors are responding with silly and/or incorrect information and it takes some back-and-forth to get it fixed. Once it scans clean, then a new version can be released.
Right now I don’t know of any issues in the installation process or the support scripts that need fixing, and I don’t think there are any features (at this time) that need to be added to support a clean and simple install/uninstall of Syncthing. If you want an installer for the new version, you can install 7-Zip and Inno Setup and follow the Building page to generate an installer executable for the new version.
I can’t quantify exactly how much it helps, but I have the impression that signing the executable with a proper certificate doesn’t hurt. What’s your build setup? I didn’t see something immediately obvious on the repo, but if there’s a public, reproducible build somewhere maybe we can add a step to sign it with our certificate. (Because I know first hand that those are both expensive and annoying to get, so I’m not going to ask you to do that.)
Hi Jakob, thanks! The build process for generating the executable is here:
Does that help?
It helps cementing that I have no inclination to attempt that. I was thinking of a GitHub action, other CI-provider setup, docker image, or similar that runs automatically and produces a binary we can reasonably assume is the result of the public source code and process.
Ah, I see. I don’t have any experience with any of those things unfortunately. Looks like I will need to do some research on this. Which of these would you recommend, seeing as it is likely the build will need to occur on a Windows machine?
I don’t have that much experience building things on Windows, but my first attempt would be to get it running with GitHub actions, as that will be free and integrated with the source repo.
I’ll investigate on my free time, which basically means it’s not going to happen anytime soon (if it even happens at all).
If it makes it easier: If you could create a script that executes what building.md describes, including getting dependencies, that should make it possible to run it and thus create the release in our CI (please correct me if I am missing something @calmh ).
Powershell is the native windows thing. I think python or bash should be also be doable to setup, but I’d need to check how that works first.
The output executable gets built by Inno Setup (a Windows-only application), so presumably the automatic build would have to occur on a Windows host.