I wanted to ask the community for comments, guidance and experiences regarding the “npm install” step in the developer guide, please.
Specifically, how are you handing cases where the given npm installation provides or invokes modules which are flagged by npm audit as “high” or “critical” in severity?
<ASIDE>I realize that these flags will frequently be present in development branches, or may exist generally for development reasons. In a pure development context, lowered security and greater risks are accepted---devs often strive first for compatibility with modern components.</ASIDE>
I am especially interested to hear from folks who are adopting and/or customizing Jitsi (perhaps “downstream”) for organizational, production use cases (such as the classroom).
- Do you take some steps to mitigate these flags? What and how?
- Would you mind sharing your experiences?
Without pointing to specific examples, I feel that locally patching or force-fixing any flagged npm modules (e.g. with more their more-stable versions) would result in builds that are not comparable with the public release. So practical testing and functional equivalence (as compared with the public release) would be lost.
- Is there a process or workflow that works well in your scenario?
Thanks to all for sharing any insights, and thanks to the Jitsi developers who’ve made the software open and accessible.