ETA: apparently ‘Artemis’ isn’t a virus/trojan. it’s the mcafee heuristic checking engine. it sees something that sorta looks like it could be new malware, and it’s flagging it. It’s not recognizing it as something previously known. Not that that helps.
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.
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.
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.
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.
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?