I cross compile 64tass under Linux using mingw-w64 as well (currently version 10.2.1). Checked and the release here and it was not tampered with.
Probably someone managed to create a too broad signature again resulting in this false positive. Hopefully it'll generate enough trouble that the next update will refine it. I personally won't waste my time complaining at AV vendors about their false-positives.
It was always sort of annoying and had to stop using executable compression for this reason decades ago. For some reason their logic went like this: viruses tended to be compressed, compressed executables are a rare sight, therefore everything compressed is suspect. Reversing this logic gives that these days mingw-w64 must be a popular choice for certain kinds of development...
Using another compiler might help but as a quick alternative I only have mingw32 4.4.4 (for vintage stuff) with its incomplete libraries. If I remember correctly aborting with control+c isn't supported for example. Or OpenWatcom 2.0 but the result isn't feature complete there either. It is possible to use MSVC natively as far as I know as I got a few reports about that whenever I broke it accidentally but that's not an option for me.
For now I'll leave this bug open as a reminder that I need to look for ways to avoid providing my own executables for windows in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meanwhile I've created a mingw package for msys2 and sent in a PR. If it goes through there'd be windows builds using the latest toolchains for both 32/64bit and even arm.
By the way last week I tried recompiling with the old mingw32 4.4.4 and it really did the trick to avoid that false positive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do the 64tass zips get built?
I built my own EXE on macOS (using the MacPorts mingw-w64 package), and virustotal flagged that as well: https://www.virustotal.com/gui/file/79b7df2402df55009ec14327f5464d75ee99fd091025af2a1043c1bdb456df78/detection
--Tom
Hello!
I cross compile 64tass under Linux using mingw-w64 as well (currently version 10.2.1). Checked and the release here and it was not tampered with.
Probably someone managed to create a too broad signature again resulting in this false positive. Hopefully it'll generate enough trouble that the next update will refine it. I personally won't waste my time complaining at AV vendors about their false-positives.
It was always sort of annoying and had to stop using executable compression for this reason decades ago. For some reason their logic went like this: viruses tended to be compressed, compressed executables are a rare sight, therefore everything compressed is suspect. Reversing this logic gives that these days mingw-w64 must be a popular choice for certain kinds of development...
Using another compiler might help but as a quick alternative I only have mingw32 4.4.4 (for vintage stuff) with its incomplete libraries. If I remember correctly aborting with control+c isn't supported for example. Or OpenWatcom 2.0 but the result isn't feature complete there either. It is possible to use MSVC natively as far as I know as I got a few reports about that whenever I broke it accidentally but that's not an option for me.
For now I'll leave this bug open as a reminder that I need to look for ways to avoid providing my own executables for windows in the future.
Meanwhile I've created a mingw package for msys2 and sent in a PR. If it goes through there'd be windows builds using the latest toolchains for both 32/64bit and even arm.
By the way last week I tried recompiling with the old mingw32 4.4.4 and it really did the trick to avoid that false positive.