url_handler.exe detecting as a virus (Gen:Trojan.Heur.RP) by some anti-virus programs

[PatrykMis]

Compiled few times by scons and by make.bat. Each result submited to virustotal.com, here is the link of the last submission: https://virustotal.com/en/file/3d8b4e9c5436947afe3b7da196b8d60af29e1c1001bd42d8dab6fa5f0eb8b1cc/analysis/1486719167/

Additional info: Windows 7 sp1 x64

32-bit versions of: Python v2.7.13 (from python.org) sconstruct v2.5.1

[LeonarddeR]

Might be that this has to do with the fact that the executable is not signed. The only solution which doesn't cost money which I can think of, is asking @nvaccess whether they are willing to sign the executable with their certificate.

[seanbudd]

I would encourage contacting the VirusTotal vendors. With the new virus scanning added to the Add-on Store, the policy is to no longer accept add-ons with vendors flagged. It's worth trying to unflag both NVDARemote and url_handler.exe. Perhaps url_handler.exe should remain a pre-built dependency so that it doesn't get re-flagged in future.

https://www.virustotal.com/gui/file/58313ee1542ace3e878be617a0ec41fd74ad341a21cb7104a474c8888298851e/detection

[ctoth]

Given we have no control over Virustotal, I recommend adding a whitelist to your add-on store with confirmed false positive hashes.

[seanbudd]

We can't confirm this as a false positive without building the exe ourselves. In order to handle this particular case, we are planning on including url_handler.exe in a future release of NVDA. This is partially due to our goal of eventually supporting similar features as NVDA remote. Note in the meantime: reaching out to the vendors flagging content is generally a painless process, we have to do this semi-regularly for NVDA releases. We are in the process of scanning all existing add-ons with VirusTotal, which will give us a better understanding of the scale of this problem before proceeding further on this policy.

[seanbudd]

https://github.com/nvaccess/nvda/issues/16714