I updated gallery-dl via scoop and when executed, Malwarebytes stopped the exe and identified it as Malware.AI.4267752956. The previous version 1.14.3 do not have this problem. I don't know if the problem is gallery-dl or Malwarebytes software, I just wanted to report it. Keep up the good work.
Most likely a false positive. I also have Malwarebytes and have had no flags on any version of gallery-dl.
I admit that I update using pip on Windows 10, FWTW.
The best you can do is file a false-positive report to Malwarebytes.
https://www.virustotal.com/gui/file/0302a897055546b250a0e443c7f322d28b34d3fbf4325e91363fb1fcf0f71a67/detection
Seems like MalwareBytes is not the only one, seems like the packager did some dodgy stuff.
Has anyone tested whether this is an issue with scoop delivery only?
Are these detections present with Chocolatey, snap or pip installations of gallery-dl?
I've scanned my pip installed gallery-dl.exe in my scripts folder with both Malwarebytes and Bitdefender and have had no red flags detected.
This is due to changes in pyinstaller, it seems. For the 1.14.4 release, I've used pyinstaller version 4.0, whereas previous releases only used a git snapshot of pyinstaller before 4.0 to build the standalone executable.
There is now a new 1.14.4 exe built with https://github.com/pyinstaller/pyinstaller/tree/f7168c866d7f2d583bf6eb00fbab647a513f64c1, which only gets detected by 6/68 engines virustotal link
I've also tested this with the current pyinstaller dev version, and the executable produced by that gets flagged 22/68: virustotal link
@biznizz
Are these detections present with Chocolatey, snap, or pip installations of gallery-dl?
I powered the snap packaging of gallery-dl and can be confident that, as long as the source tree is benign the resulting snap package will also be benign. This is due to the fact that we don't have control of the building infrastructure(which belongs to Canonical, inc, the company behind Ubuntu).
For the Windows build, it would be more reassuring if we can reproduce the build ourselves, which, isn't seemed to be possible for now as the build seems to be started from a custom Windows VM.
Same. Mine was Windows Security.

The security provider is Microsoft Defender Antivirus.
A new release with a new executable is out, which hopefully doesn't make as many problems.
(I've used the same pyinstaller snapshot as linked above)
If anyone wants to reproduce the build, here is the .bat file used to build the executable on a x86 Windows 7 VM:
py -3 -m pip install -U pip
py -3 -m pip install -U setuptools wheel
py -3 -m virtualenv E:\venv-win32
E:\venv-win32\Scripts\python.exe -m pip install requests
E:\venv-win32\Scripts\python.exe -m pip install urllib3
E:\venv-win32\Scripts\python.exe -m pip install youtube-dl
E:\venv-win32\Scripts\python.exe -m pip install https://github.com/pyinstaller/pyinstaller/archive/f7168c866d7f2d583bf6eb00fbab647a513f64c1.tar.gz
E:\venv-win32\Scripts\python.exe E:\gallery-dl\scripts\pyinstaller.py
In short:
pip, setuptools, wheelvirtualenvrequests, urllib3, youtube-dl, pyinstaller@mikf latest release gets quarantined by Windows Defender.
@github-account1111 Throw Windows Defender in the trash or download it via pip.
https://www.virustotal.com/gui/url/55c1c67dc4d3e5b3fa75e6e76a13469d79064a28fdd3f9408ed912d330849492/detection
Throw Windows Defender in the trash
Please, don't. Just wait for a definition update. 馃槂 (Or use pip, yes).
@kattjevfel You get quite a different result when manually uploading the .exe file:
https://www.virustotal.com/gui/file/b3ac6519ed465d75e4b6af4311def3c3d40ca5c0465cdbb13837b1aa97e848ce/detection
Older versions of gallery-dl (1.10.0 in this case) aren't much different though, but don't get flagged by Windows Defender:
https://www.virustotal.com/gui/file/0fdf9c6210153e9765682ae2d8c6eb2ff30b89c566c1512f6fcdb8737869dce8/detection
I haven't changed anything for 1.15.0 when building the standalone exe. It's still the same method as explained in https://github.com/mikf/gallery-dl/issues/947#issuecomment-683461030, so who knows why Windows Defender is acting up now.
Most helpful comment
This is due to changes in pyinstaller, it seems. For the 1.14.4 release, I've used pyinstaller version 4.0, whereas previous releases only used a git snapshot of pyinstaller before 4.0 to build the standalone executable.
There is now a new 1.14.4 exe built with https://github.com/pyinstaller/pyinstaller/tree/f7168c866d7f2d583bf6eb00fbab647a513f64c1, which only gets detected by 6/68 engines
virustotallinkI've also tested this with the current pyinstaller dev version, and the executable produced by that gets flagged 22/68:
virustotallink