Insecure indirect dependency to xmldom via plist

[mdreier-sap]

Preflight Checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.

Issue Details

• Electron Packager Version:
  • 15.3.0
• Electron Version:
  • 13.2.2
• Operating System:
  • Windows 10
• Last Known Working Electron Packager version::
  • n/a

Expected Behavior

electron-packager should not have insecure dependencies.

Actual Behavior

Installing a dependency to electron-packager causes xmldom@0.6.0 to be included into the dependencies. This version has an open vulnerability CVE-2021-32796. The dependency is coming via plist@3.0.3

To Reproduce

npm init
npm install -d electron-packager
npm ls xmldom

Additional Information

plist has an open issue to update their dependency: TooTallNate/plist.js#111. electronpackager should update their dependency once plist is updated.

[welcome]

👋 Thanks for opening your first issue here! If you have a question about using Electron Packager, read the support docs. If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. Development and issue triage is community-driven, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[malept]

Thanks for the issue, but Electron Packager uses Dependabot to automatically upgrade dependencies as needed. The issue tracker is used to keep track of the project's backlog, and this will be handled automatically by the bot if necessary (depending on how plist deals with the PR).

Because of this, I'm going to close this issue as there's nothing for the maintainers of this project to do.

The dependency updater for your project should handle this automatically once plist updates.

[malept]

For the record though, Electron Packager's use of plist is effectively reading plists from the prebuilt Electron binary, and user-supplied plists via options such as extendInfo. Users of Electron Packager would really only be vulnerable to the CVE if they are using either a prebuilt Electron binary that doesn't come from electron/electron and hasn't had its plists vetted, or they have not vetted the plists that they are providing via the aforementioned Electron Packager options.