V7 virusscan false positives ... again

Last time this came up was in 2020 with v5.2.0 (the false positive offender being libsqlite3-0.dll)

This time, detected by McAfee today in both the 7.0.90 and stable builds for w64 (don’t have it on my system anymore to check which hg id, but sometime in the past couple weeks after 7.0.90):

here’s the virustotal link showing (currently) 7/66 scanners flagging it as an Artemis trojan.

Detecting Product Name: McAfee Endpoint Security
DAT Version: 4685.0
Engine Version: 6300.9389
Target Name: dbus-run-session.exe
Event Category: Malware detected
Threat Name: Artemis!596A4065E81F
Threat Type: Trojan
Target Hash: 596a4065e81fa2712ec5291543a4ce8b

we don’t really need that file, right? last time we had to go through submitting the 5.2.0 file for individual whitelisting with all the major vendors. I’ll at least start with mcafee when I can.

since last time was captured on the mailing lists, archive links:
McAfee whitelist request process (maintainers): McAfee whitelist request
“Trojan warning!” (help): trojan warning!
User trojan notification: GNU Octave website hacked and links replaced with trojan-containing inst

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.


I have uploaded samples to the false positive reporting options at AVG, Avast, Avira, F-Secure, and Cynet.

McAfee requires the ability to email a password protected zip attachment, which none of my email clients will let me do. If someone whose email client wont block such things could attempt the process described at

it would be appreciated.

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.

1 Like

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.

1 Like

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.

1 Like


  • 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.

1 Like

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.

dbus-run-session.exe comes from the dbus package that has to be built in order to compile QT.

We went from v1.13.18 to v1.13.20 in Dec 2021.

I dont think the launcher is ever acually run so may not need it

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?

Not sure - also not sure how widely in use dbus is in windows.

mxe.cc is using same version as us, however mingw-w64 is using an older version

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.

I pushed mxe-octave: 9df7598d4b90 so that several of the support tools are not installed

awesome. I can never keep track of which build is which. which of the w64 buildbot images would this change appear in?

also, in the interest of keeping a minimal install footprint, are there any other things like this worth considering for removal?

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:

  1. A change in the octave-mxe repo is 1-2 days later build (the build is triggered once per day at UTC+0 midnight).
  2. 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 :sweat: ).

I think adding this point the checklist is good, to at least not forget about this issue :wink: If this point turns out to be not useful, it can be removed or modified anytime. So please go ahead :slightly_smiling_face:

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?

installed-packages/hdf5.files:-rwxr-xr-x bin/mirror_server.exe

Change log for hdf5.mk: HDF5: Update to version 1.12.1.

Current package is installing:

-rw-r–r-- include/H5Apublic.h
-rw-r–r-- include/H5FDmpi.h
-rw-r–r-- include/hdf5_hl.h
-rw-r–r-- include/H5FDmulti.h
-rw-r–r-- include/H5VLnative.h
-rw-r–r-- include/H5VLconnector.h
-rw-r–r-- include/H5FDmirror.h
-rw-r–r-- include/H5VLconnector_passthru.h
-rw-r–r-- include/H5Mpublic.h
-rw-r–r-- include/H5Epubgen.h
-rw-r–r-- include/H5Ipublic.h
-rw-r–r-- include/H5ESpublic.h
-rw-r–r-- include/H5FDhdfs.h
-rw-r–r-- include/hdf5.h
-rw-r–r-- include/H5TBpublic.h
-rw-r–r-- include/H5FDwindows.h
-rw-r–r-- include/H5Rpublic.h
-rw-r–r-- include/H5Zpublic.h
-rw-r–r-- include/H5Epublic.h
-rw-r–r-- include/H5FDcore.h
-rw-r–r-- include/H5DOpublic.h
-rw-r–r-- include/H5pubconf.h
-rw-r–r-- include/H5api_adpt.h
-rw-r–r-- include/H5Ppublic.h
-rw-r–r-- include/H5PLextern.h
-rw-r–r-- include/H5LDpublic.h
-rw-r–r-- include/H5Cpublic.h
-rw-r–r-- include/H5FDlog.h
-rw-r–r-- include/H5IMpublic.h
-rw-r–r-- include/H5ACpublic.h
-rw-r–r-- include/H5FDdirect.h
-rw-r–r-- include/H5VLpassthru.h
-rw-r–r-- include/H5FDs3comms.h
-rw-r–r-- include/H5FDstdio.h
-rw-r–r-- include/H5MMpublic.h
-rw-r–r-- include/H5Gpublic.h
-rw-r–r-- include/H5Tpublic.h
-rw-r–r-- include/H5FDpublic.h
-rw-r–r-- include/H5Dpublic.h
-rw-r–r-- include/H5Opublic.h
-rw-r–r-- include/H5FDsec2.h

ok, the bit of googling i did brought up a little about hd5, so that makes sense.

would be curious to see if other programs with the same package get flagged the same way, or if it’s something unique to how octave is building it.