I did email them requesting FTP access. they do seem to have a page where the ‘company’ could request ability to submit regular builds to their whitelisting server. that could be worthwhile.
heard back from AVG, Avast who tested the file as clean and whitelisted it in their database. Avira report said ‘scan came back clean’, so hopefully they’re doing the same. Cyren informed me they are not Cynet (whoops), and McAfee sent a form for the company to request access to their scanning/whitelisting database.
noting that the viruscan link shows AVG and Avast already showing clear scans.
as of this morning only McAfee reporting. I’ll fill out their request with my contact info if there’s no objections so we can move it forward. I’d like to be allowed to have v7 on my work machine again.
McAfee still reporting - their email support insists they’re whitelisting it and getting fixes in their definitions to stop triggering, but it’s ‘in process’.
TrendMicro-HousCall started reporting. I submitted a whitelist request/upload but haven’t heard back.
all others showing as clean.
v6.4.0 has the same dbus-run-session.exe file, but it does not get detected. Is that part of octave or mxe-octave? I’m curious if anyone can point to obvious changes made to that utility file.
just an update that there has been no change to false positive detection status of this file with those two vendors.
If another RC is produced for Octave 7.1, I would suggest someone immediately upload the dbus-run-session.exe file from the w64 version to www.virustotal.com and see if it triggers the scanners.
Unfortunately, without knowing what changed from 6.4.0 to 7.0.90 in that file, it may be that Windows users running McAfee will have trouble using 7.1 when it releases until this whitelisting actually takes place.
interesting. that would match the timing with reports starting in January that I’m seeing . Think everyone who uses 1.13.20 is getting this or are we doing something different?
Ok. I just noticed another one popped up as positive on the virustotal list. I manually emailed them the file, but am not holding my breath. I think some have algorithms that use other results to make their own determination, so it snowballs.
Was hoping a month ago that this would be quick to resolve. As is, if it doesn’t change soon anyone at least running mcafee won’t be able to use 7.1 without the malware issue. Prevents its use on our managed systems.
If the file didn’t need to be there, might be easier if it just wasn’t.
Im not sure what build bot images - its in the dev and release mxe builds,
There probally other things that can be removed. A lot of the user documentation of libraries is already being not installed, If makefile targets were consistently named, it would be easier to stop
A while back there was a developer meeting that mentioned adding ‘submit the windows builds to virustotal.com’ to the 6.1 release checklist. Think that would be a good idea for the 7.1 checklist, and maybe as part of the formal process for each version? When the 5.x version was setting off the scanners, the .exe installer was detected differently from the installed files. so assuming there’s not a filesize limit, would make sense to scan both exe and zip versions.
I think you mean the buildbot builds from https://buildbot.octave.space? This is indeed a little rocket science. Two rules of thumb:
A change in the octave-mxe repo is 1-2 days later build (the build is triggered once per day at UTC+0 midnight).
A change made to “release” is available in all MS Windows installers. A change to “default” only in what I call “mxe-default”.
So in the case of discussed cset all MS Windows installers are changed (“release”) and all builds since about six days (at least from tomorrow) have incorporated this change. (P.S.: I do not like that in hg one can push csets with almost arbitrary old dates ).
I think adding this point the checklist is good, to at least not forget about this issue If this point turns out to be not useful, it can be removed or modified anytime. So please go ahead
While it is true that most changes on the release branch are merged to the default branch, not all of them are. And changes that aren’t merged yet (like in this case) also don’t appear on the default branch.
So, this particular change (hg id 9df7598d4b90) is currently only part of the nightly builds that don’t contain “-default-” in their name.
looking at the current state of Octave 7.1.0 w64 - virustotal results, the only Octave files being flagged anymore are mirror_server.exe and mirror_server_stop.exe in /mingw64/bin. I noticed these files are not present in Octave 6.4.0. Do we know what change or added function prompted their inclusion? Do they also fall under a ‘not strictly needed’ category like the dbus-run-session file?
).
If this point turns out to be not useful, it can be removed or modified anytime. So please go ahead 