ASAR Native Module unpacking triggers virus scanners

[anaisbetts]

We're seeing a lot of tickets where ASARs unpacking of native modules to temp files is triggering AV vendors to mark the app as a Trojan Horse and start deleting files. We probably need to move to unpacking these files to a static location (this would also help with startup perf because we wouldn't be constantly unpacking files).

[pfffr]

Perhaps those snakeoil av vendors should not "detect" every bit of JavaScript as Win32:Evo-gen. But - good idea.

[anaisbetts]

@pfffr I'm not disagreeing :) But in the meantime, we have to solve the issue or else ASAR isn't tenable to use in production Windows applications

[anaisbetts]

I would suggest that under the data directory (i.e. the one pointed to by userData) create a new directory called modules, and unpack the node modules there, using their original names. If the file already exists, use it, don't unpack. If someone can point me towards the place where we do the unpacking I can submit a PR

[pfffr]

Wouldn't that still trigger the AV-foo on the first extraction and on any auto-update process too?

[anaisbetts]

@pfffr It will, but hopefully less so because we're not using temp files, and ideally we won't be doing it constantly (i.e. once it's unpacked it's done)

[pfffr]

@paulcbetts I'm totally with you. %allusersprofile%\ASAR (or .asar) would be the right destination for those files, IMHO. Otherwise %appdata%\ASAR i.e. for further usage for current user.

[zcbenz]

@paulcbetts I think we can just don't include the shared libraries in asar archives, so we have following layout:

resources/
├── app.asar
└── app.asar.unpack
    ├── node_modules/keytar/build/Release/keytar.node
    └── node_modules/pathwatcher/build/Release/pathwatcherr.node

And when reading files we would first look into app.asar.unpack to see if there is already an unpacked file, and then look into app.asar if not.

This solves the virus scanner problem and improves performance. It requires changes to both atom-shell and asar utility, so I probably don't have time for this before the upgrade to Chrome 41.

[anaisbetts]

@zcbenz That works for me. So far, most vendors are okay with the current approach except for a few (WebRoot is the worst) that really get upset :-/