Lexikos
commented
4 months ago No. How could it be an issue with the release script? I lay the blame entirely on those vendors. I have no more actual knowledge about their detection systems or criteria than you do, and no power to do anything about it except to keep updating AutoHotkey and hope that the next signature doesn't get flagged.
Previous versions are by definition older than the current one, and have had time to be analyzed or reported to various vendors, to build reputation, to provide positive data points for systems based on machine learning, or however else it might work.
False positives often affect only the setup.exe and not the main binary files. They have been occurring basically forever, through various changes to the packaging (which were sometimes attempts to reduce false positives):
- Interpreter binaries compressed with UPX or mpress, or not compressed.
- NSIS installer.
- Self-extracting 7-zip archive custom-built for small size and no GUI.
- Self-extracting 7-zip archive based on official 7-zip binaries.
- Digitally signed (with open source certificate issued by Certum) or not.
- The current setup: a compiled script compressed with UPX.
In general, issues with a release should be raised on the forum, either Bug Reports or Ask for Help v2 (usually the latter) depending on the nature of the problem. For false positives, raising the issue anywhere is generally futile. I think the only chance at a solution is for people to hound antivirus vendors with reports of false positives, every time it happens (and it will continue to happen, probably indefinitely).
The latest AHK2.0.12 release was flagged by 27 vendors for being malicious. This is substantial enough to get it auto-deleted by some aggressive A/V clients, especially those in corporate environments.
Previous versions including 2.0.11 were not flagged by more than 6 vendors (out of 72) and did not have this issue.