Open opello opened 11 months ago
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...
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