mintty
VirusTotal Detections
Looks like Chocolatey is not going to update with the VirusTotal reports, i686 is 6/71 and x86_64 is 5/70 for the portable installers.
I didn't see how the builds were constructed and so didn't really know how to iterate and test.
See also #181
Thanks for the hint. However I can only point you to one of the other installation options as listed on the project page.
I do agree that projects and user should update software packages and use the latest one (if possible). I would also suggest not to follow VirusTotal reports blindly. How many of those 6/71 antivirus vendors are well known? There are many false positive reports for binaries from cygwin environment.
I would also suggest not to follow VirusTotal reports blindly.
I understand this and wholeheartedly agree. I sought an administrative override and was denied before reaching out here. The Chocolatey admin told me it would not be approved with the current levels of reports.
How many of those 6/71 antivirus vendors are well known?
I'm not as up on the reputation of the VirusTotal scanners as I once was so can't really comment off-the-cuff on the legitimacy of the various detections.
Not to quote myself, but:
I didn't see how the builds were constructed and so didn't really know how to iterate and test.
Is there any documentation or scripts for how to build these installers?
Which installers? The chocolatey ones? See project page: this is a 3rd-party installer not supported here (you're still free to ask and hope someone might respond...)
Or the wsltty installers published here? See project page: this is all generated on a cygwin platform, simply running make.
OK, admittedly, the project page tells you how to install locally from cygwin, but it does not say explicitly how to build the installers. I will add that.
Great, thanks!
The chocolatey ones? See project page: this is a 3rd-party installer not supported here
This seems like an inconsistent position to adopt when Chocolatey installation instructions are included in the documentation. It's also not like the maintainer of the Chocolatey package rolled their own installer, it uses the portable one released here. But I can appreciate not so directly assuming responsibility for it.
I hadn't noticed the makefile and it seems the iexpress makewinx.cfg.
Makes me wonder why the overlay tag was applied at VirusTotal:
overlay: The file contains an overlay, appended data at the end of the file, may be some additional malicious payload.
Or if iexpress of whatever the host version is just triggers that no matter what...
One recommendation I came across was digitally signing to avoid false detections. I wonder if that's at all possible here? It came up recently for ImageMagick. Discussion was around SignPath and what they eventually went with, Azure Code Signing.
I had considered Signpath already, which seemed to be a startup project at that time but looks more advanced now. Maybe I'll take another go. I'd actually prefer contribution by someone familiar with signing processes.
I'd actually prefer contribution by someone familiar with signing processes.
I'm willing to help. My code signing experience is a bit old but was for Windows drivers and executables. Seems like if there's any resistance on the SignPath front following the ImageMagick path of Azure Code Signing is pretty well documented by way of the above, as well as other places. I also found more detailed SignPath documentation not exactly clearly linked.
I just don't know what the incentives or prohibitions are for adopting one path or another.
I'll open a separate issue to describe expectations to a signing process. For now, just note that all those excessive descriptions appear to be deterrent. More detailed means more complex and a lengthy description may be well described but certainly not pretty.
Sounds good and makes sense.
I don't know that I exactly agree with this pejorative use of "excessive" when there are as many ways to solve a problem as there are people that might have solved it. At that point if one cares to reinvent a rounder, more smoothly rolling wheel so be it, but choosing an existing one that aligns with your requirements and meets your needs is a question of evaluating those available. And just because everyone's requirements and needs are slightly different doesn't inherently mean that a process is unwieldy. Nor does it preclude it, but, to assume seems unreasonable.
I also wonder if moving the installer packaging to WiX or NSIS would side-step the issue. Any thoughts on that front?
Back on the topic of VirusTotal Detections, I ran a simple test with the iexpress that comes with Windows 10:
https://www.virustotal.com/gui/file/af1f1d82a1a3cfe5ed04c9fe05c093f649fd28765b1d9e3c93e14e058a85ff78/detection
This may not be a fair comparison test because all it contained was cygwin1.dll and the Details page on VirusTotal didn't seem to detect that correctly. I also used naive SED file settings from clicking through the UI instead of being as close as possible to the SED file here. But either way the VirusTotal response is pretty revealing insofar as false positives go, there were 9/72 detections from an iexpress produced SFX package that contained cygwin1.dll, which itself has 0/70 detections.
A follow-up from Chocolatey suggested manual approval may be forthcoming if documentation of the VirusTotal false-positive situation was made. And was in the v3.6.5 moderation comments:
If there a known reason that this software may have a high rate of false positives, please link to the upstream documentation (for example it could be an issue or wiki) in the package description. Then ask for an exemption and a moderator will review the documentation. If there is not a known and documented reason, please contact the software authors to see if they have any reasons they can document.
Anyway, my assumption is that VirusTotal is using detectors that false-positive on iexpress. Likely because of the amount of use it has in the security community. At the very least later I'll try playing with the packaging and running through VirusTotal. It seems more productive than trying to interact with the tool vendors VirusTotal uses?
Status Update: I did end up trying to reach out to the various contacts I could find for the false positives. The one that did hear back from, Bkav, was happy address the issues, but it seemed to me that they were simply whitelisting the files in question. That didn't seem like a real long-term solution and I gave up after 6 rounds of test files trying to illustrate how the general problem hadn't been resolved.
It does seem like the original VirusTotal uploads have seen some action as they now report fewer (3 each) detections. Strangely not the same engines between the two files. So maybe the bug reports helped and they just never let me know...
How is this completed? I checked the 3.8.0 release artifacts and they don't appear to be signed. I checked them on VirusTotal and:
- wsltty-3.8.0-x86_64-install-portable.exe (7/71)
- wsltty-3.8.0-x86_64-install-quiet.exe (6/70)
- wsltty-3.8.0-x86_64-install.exe (7/70)
So reopening. I was assuming this to have been an incidental hit; I didn't know VirusTotal would flag all software as suspicious that is not signed. (Is that the purpose of anti-virus detectors, to push people into the effort of cumbersome signing processes?) Anyway, enough ranting, there's still no concise advice available (I'd be aware of) how to pursue an open-source signing process with low effort. I know, I wanted to provide some requirements from my point of view which I didn't...
I was assuming this to have been an incidental hit; I didn't know VirusTotal would flag all software as suspicious that is not signed.
I wrote this in https://redirect.github.com/AeliusSaionji/chocopkgs/issues/66 but reiterating here:
The reason is iexpress.exe generated installers are commonly used in pentesting and malware packagers so it's essentially been fingerprinted as universally bad, despite it's more humble beginnings.
It looks like the ImageMagick blog post moved and it seems they've moved from using the specialized signing GitHub Action for signing to running SignTool (609c44a84f8ec824b2b8412c0e7effc38d483949 and b788839d79328938f3b7147181fa2e348f04e0c2) fairly recently. I imagine the volatility suggested by more recent changes is an argument against the process, but it does seem to have gotten simpler. Their actions for signing: application and installer if you'd like to review that. But that is just the last piece and doesn't cover getting set up in Azure for signing.
Thanks for the info, which means the situation has basically not changed. Azure is a commercial platform. If someone interested in signing provides full working info (like a PR), I will take it. Until then, there's still the winget and scoop packages as an option.