Closed cw433 closed 9 months ago
Came here to report that Windows Defender marks it as malicious.
I haven't noticed as I exclude the scoop directory from Windows Defender scanning. Obviously there is some risk to this, but I just have to trust the scoop package maintainers. I did this previously there had been a couple of packages with false positives due to the compression used on the binaries.
You can exclude the scoop directory in an elevated PowerShell prompt:
Add-MpPreference -ExclusionPath "$($env:programdata)\scoop", "$($env:scoop)"
Or where scoop-search.exe
and add that directory, which for me would be:
Add-MpPreference -ExclusionPath "C:\ProgramData\scoop\shims"
Thanks @eggbean, while this might be ok for some, I'm sure the maintainer does not want their application flagged as malware. + with 29 vendors marking the latest scoop-search.exe as a Trojan, maintainer should check their build environment for risks on their end.
My Malwarebytes also flagged this. scoop-search
is automatically installed by WingetUI.
Dear all. Last 4 issues have been about exactly this, and I have closed all of them as a wontfix simply because there is nothing I can possibly do. But let me take a different approach:
I have zero experience with antimalware software so I urge you for help with this matter to get to the bottom of this. On my side: every dependency is up to date, which is actually only github.com/valyala/fastjson which does not have any dependencies of its own. Last commit was over a year ago and a quick glance over the repository does not reveal any issues. Furthermore, the dependencies of the CI runner (github actions) are also up to date and standard tools used by the community. The binary that is released on github is that one which is built by the CI. This is fully automatic. The Golang version used to build is also the most recent version.
If someone has experience in this area I would gladly accept help to understand where the problem lies. For instance, could anyone that has Golang installed try to build the project and see if the built binary is also flagged as malware?
After some digging I have found that windows antivirus software seems to just not like Golang binaries. A few reports have said that signing the binaries has helped. This is totally unnecessary but if I have to do that then I will.
Hello @shilangyu,
I have also faced this issue when developping with Python and PyInstaller.
When building software with a compiler that always bundles certain runtimes into the executable (for example, Python3.dll or the golang libraries in the case of go), AVs somtimes detect a real virus built with the same technology and then start blocking any executable that resembles the previously detected virus, resulting in a ton of false-positives.
For me, the solution that really worked was finding a specific Python version that was, for whatever the reason, less triggering for AVs. I have since then stuck with Python 3.11.3 and will do so until a newer version can be used safely. I suppose it could be done with this library also, finding a go version that for some obscure reason gets blocked less on virustotal.
Finally, signing will definitely give more trust (in terms of AV reputation) to your binaries, but it will NOT eliminate the issue completely. Some AVs may (and will) still flag your signed binaries as virus.
Finally, as the developer, you should reach to Microsoft through this form (https://www.microsoft.com/en-us/wdsi/filesubmission) and report the false positive. In two or three days they will have removed the false positive from MS Defender, the most used AV among Windows users.
[DISCLAIMER: I AM NO CYBERSECURITY EXPERT] As it can be seen, most of the detections are Generic
or PossibleMalware
, without specifying any specific detection.
[DISCLAIMER: I AM NO CYBERSECURITY EXPERT] Some of this flags were the same ones I received in the past (Wacapew, Wacatac, Trojan.Genetic, TroGen, etc.) so it looks for me as if they are false positives.
Sentinel One MDR flags this. I just use sfsu search
now.
Taking look at sfsu inspired me to rewrite scoop-search to be faster and without a runtime to hopefully not be flaged by anti viruses. Hopefully will have results by the end of the weekend.
Initial results are encouraging, rewrote scoop-search in Zig https://github.com/shilangyu/scoop-search/pull/45. The implementation is naive, will resume work on it tomorrow. Once I am done scoop-search should be faster, smaller, and free of any runtime.
Nice to see Zig in use. Hope the rewrite resolves this issue.
I finished the rewrite. In my tests it is currently about 1.3x faster than sfsu (and 2x faster than previous version of scoop-search) and VirusTotal seems to complain much less about the binary.
Before I do a proper release (I am afraid that if I do a github pre-release scoop will pick it up as an update) I would appreciate if you could give it a whirl and see if it works fine for you. I have pushed a temporary branch with the committed exe: https://github.com/shilangyu/scoop-search/blob/temp/zig-build/zig-out/bin/scoop-search.exe. Of course I encourage you to build the binary from source if you (understandably) do not want to download an untrusted binary from the internet, using zig build -Doptimize=ReleaseFast
.
If I get a few confirmations that it is working fine, I will do a proper release so scoop can pick it up.
Can confirm working for me <3
Only 1 detection on virustotal (CyNet)
https://www.virustotal.com/gui/file/bf276a7788271c9a80bcaae909e24957ce677d17af31b227ceef81808d89bf9a
Got unsupported 16bit application error on win 11
It worked when I forked the repo and built using github action myself but the binary size is 500kb
It appears to work for me too
Thank you everyone for help, I have release v1.4.0. Closing this for now, feel free to comment if new issues arise!
The issue is indeed fixed on 1.4.0. No more positives from Virustotal and the Windows Security
Please see Virustotal: https://www.virustotal.com/gui/file/d5ab7d9d164571b21c38b137e47604b8f9785758ec6ae1b99b014bef8acca4b9/detection