Kaspersky (and others) identifies Pulsar as malware

[pietrodicaprio]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

I can't get Pulsar running due to Kaspersky blocking it for a Hoax.JS.ExtMsg.a presence.
Kaspersky is not the only one identifying a malware in Pulsar:
https://www.virustotal.com/gui/file/a79b7495fe78235cc215b79736080fee8bc3ef0c5aa04acbd8926d0b4aaf1397

Code Insight
The code you provided is a JavaScript program that prints a message in Russian that calls for peace. The program does not appear to be malicious or harmful.

Pulsar version

Pulsar-1.105.2023061120-arm64

Which OS does this happen on?

🍎 macOS

OS details

Ventura 13.4

Which CPU architecture are you running this on?

Apple M1/M2

What steps are needed to reproduce this?

Download the rolling or the regular release, try to open it: App is damaged and can’t be opened

Additional Information:

No response

[Spiker985]

Can you confirm if this still occurs on version 106 that was just released?

[Spiker985]

It appears that the file in question is a _postinstall.js file

[pietrodicaprio]

Well, that's the reason: medikoo/es5-ext#186
you should fork es5-ext and remove that message (show support to Ukraine using other methods...)

[Spiker985]

Yup, appears it's inside pulsar and ppm both

[pietrodicaprio]

downloading from the download page still provides v105 anyway

[Spiker985]

It does appear that the postinstall only executes on systems that have the following timezones:

"Asia/Anadyr", "Asia/Barnaul", "Asia/Chita", "Asia/Irkutsk", "Asia/Kamchatka",
"Asia/Khandyga", "Asia/Krasnoyarsk", "Asia/Magadan", "Asia/Novokuznetsk",
"Asia/Novosibirsk", "Asia/Omsk", "Asia/Sakhalin", "Asia/Srednekolymsk", "Asia/Tomsk",
"Asia/Ust-Nera", "Asia/Vladivostok", "Asia/Yakutsk", "Asia/Yekaterinburg",
"Europe/Astrakhan", "Europe/Kaliningrad", "Europe/Kirov", "Europe/Moscow",
"Europe/Samara", "Europe/Saratov", "Europe/Simferopol", "Europe/Ulyanovsk",
"Europe/Volgograd", "W-SU"

And would be stuck inside the Console - but this is still quite troubling

Especially since it has been there since 2022-03-07

[pietrodicaprio]

Indeed it's not executing on my system (CEST timezone) but the code is still checked and the execution of the entire program is not allowed. In the support section of Discord there is a post about Chrome's Advanced Protection blocking Pulsar download and that's probably for the same reason.

[confused-Techie]

So I want to add here, I'm taking a look at where or why we are including es5-ext within Pulsar.

I'm pretty sure I've been able to track down what's causing it to be installed. Essentially, through a long line of dependencies, at one point we depend on property-accessors Which is one of our package's, had the dependency es6-weak-map which through another collection of dependencies, uses es5-ext. But about 7 years ago, this dependency was removed.

So ideally if we could get everything using the most modern versions of property-accessor then we should be able to stop relying on es5-ext within Pulsar itself.

So really, it may be best to publish a new version of property-accessors on our NPM org, then afterwards find all usages of this and ensure they are all up to date.

It seems that property-accessors is depended on within:

• atom-keymap@8.2.15
• emissary Which is an Atom repo, but for some reason we don't have it forked??

The other hardpart, is that we would have to ensure we are using the same version of emissary every where. Since right now we are using emissary within:

• grim Luckily, in recent versions grim no longer depends on emissary and instead uses event-kit. So we just need to update the version of grim being used by scoped-property-store
• pathwatcher
• second-mate
• text-buffer

So unfortunately, due to the extreme way in which Atom made everything rely on everything, it'll be a bit of a mess to remove this single dependency. But totally possible, and hopefully if we can address these issues within Pulsar, and figure out where the problem is in ppm then we can get rid of these concerns. Additionally, I want to mention, my guess is this issue stems from the first-mate dependency within PPM. Since first-mate was the basis of second-mate which like mentioned earlier needs to have an updated version of emissary. So ideally by updating second-mate and moving ppm to that new version (and making it compatible with second-mate we can remove the issue from there as well.

---

EDIT MORE DETAILS:

Alright so looking further into this, I've found the exact steps that is needed to resolve this, thoroughly:

  * Update `property-accessors` to latest in:
    > Latest version of `property-accessors` no longer uses `es6-weak-map` which causes use of `es5-ext`
    - `dependencies`
    - `atom-keymap`
    - `text-buffer`
    - `emissary`
  * Update `atom-keymap` to potential latest in:
    - `dependencies`
  * Update `emissary` to potential latest in:
    - `text-buffer`
  * Update `text-buffer` to potential latest in:
    - `dependencies`

Otherwise if you'd like an exact view of what our dependency tree looks like in relation to this package:

Click to expand

> yarn why es5-ext
   - "d" depends on it
   - Hoisted from "d#es5-ext"
   - Hoisted from "es6-symbol#es5-ext"
   - Hoisted from "property-accessors#es6-weak-map#es5-ext"
   - Hoisted from "d#es5-ext#es6-iterator#es5-ext"
   - Hoisted from "property-accessors#es6-weak-map#es6-iterator#es5-ext"
   - Hoisted from "d#es5-ext#es6-iterator#d#es5-ext"
   - Hoisted from "d#es5-ext#es6-symbol#d#es5-ext"

> yarn why d
   info Has been hoisted to "d"
   info Reasons this module exists
      - Hoisted from "es6-symbol#d"
      - Hoisted from "property-accessors#es6-weak-map#d"
      - Hoisted from "property-accessors#es6-weak-map#es6-iterator#d"
   => Found "es6-iterator#d@1.0.1"
   info Reasons this module exists
      - "d#es5-ext#es6-iterator" depends on it
      - Hoisted from "d#es5-ext#es6-iterator#es6-symbol#d"
   => Found "es5-ext#d@1.0.1"
   info Reasons this module exists
      - "d#es5-ext#es6-symbol" depends on it
      - Hoisted from "d#es5-ext#es6-symbol#d"

> yarn why es6-symbol
   => Found "es6-symbol@2.0.1"
   info Has been hoisted to "es6-symbol"
   info Reasons this module exists
      - Hoisted from "property-accessors#es6-weak-map#es6-symbol"
      - Hoisted from "property-accessors#es6-weak-map#es6-iterator#es6-symbol"
   => Found "es5-ext#es6-symbol@3.1.3"
   info This module exists because "d#es5-ext" depends on it.
   => Found "es6-iterator#es6-symbol@3.1.3"
   info This module exists because "d#es5-ext#es6-iterator" depends on it.

> yarn why property-accessors.
   => Found "property-accessors@1.1.3"
   info Has been hoisted to "property-accessors"
   info Reasons this module exists
      - Specified in "dependencies"
      - Hoisted from "atom-keymap#property-accessors"
      - Hoisted from "text-buffer#emissary#property-accessors"

> yarn why atom-keymap
      => Found "atom-keymap@8.2.15"
      info Has been hoisted to "atom-keymap"
      info This module exists because it's specified in "dependencies".
      
> yarn why text-buffer
      => Found "text-buffer@13.18.6"
      info Has been hoisted to "text-buffer"
      info This module exists because it's specified in "dependencies".

But as helpfully suggested by @savetheclocktower lets go ahead and see if simply pinning the version will work here.

[DeeDeeG]

So weird that it just recently started being flagged, since as far as I can tell we've had a version of es5-ext with the message since we added yarn.lock way back in July 2022.

@confused-Techie's PR looks like a viable workaround for us being flagged.