etherpad-lite
etherpad-lite copied to clipboard
ether
npm audit command fails
This is pretty minor flaw and I must say, Etherpad is looking fantastic; great work to all the contributors! :smile:
Perhaps I'm doing something wrong and/or what I'm seeing is expected behaviour. Apologies for the noise if that's the case. I'm pretty handy with Linux, but not particularly familiar with node, so am just doing what I'd intuitively expect to work (although YMMV).
I'm fairly handy with bash, so if you can clarify what sort of "fix" you'd be open to, I'm happy to have a dig at it when I get a chance.
OS Debian 9.5/Stretch
Node: v8.12.0
NPM: v6.4.1
Etherpad: HEAD of the dev branch (currently https://github.com/ether/etherpad-lite/commit/4121add1b8b2babfb71363b3deeb254c5aa3f05f)
By running the bin/installDeps.sh from the root directory cloned from GitHub, Etherpad installed seemlessly. However, I was curious about the warning it threw up:
found 1 low severity vulnerability
run `npm audit fix` to fix them, or `npm audit` for details
and wanted to investigate a little more. So I tried running npm audit from the root etherpad-lite dir (which perhaps is the wrong way to do it?).
node@etherpad:/opt/etherpad-lite$ npm audit
npm ERR! code EAUDITNOPJSON
npm ERR! audit No package.json found: Cannot audit a project without a package.json
npm ERR! A complete log of this run can be found in:
npm ERR! /home/node/.npm/_logs/2018-10-04T03_06_23_423Z-debug.log
The log was just essentially a more verbose version of that (including versions which I posted above). So I tried again inside src:
node@etherpad:/opt/etherpad-lite$ cd src/
node@etherpad:/opt/etherpad-lite/src$ npm audit
npm ERR! code EAUDITNOLOCK
npm ERR! audit Neither npm-shrinkwrap.json nor package-lock.json found: Cannot audit a project without a lockfile
npm ERR! audit Try creating one first with: npm i --package-lock-only
npm ERR! A complete log of this run can be found in:
npm ERR! /home/node/.npm/_logs/2018-10-04T03_07_38_913Z-debug.log
Then followed the advice of that warning:
node@etherpad:/opt/etherpad-lite/src$ npm i --package-lock-only
npm notice created a lockfile as package-lock.json. You should commit this file.
audited 8198 packages in 20.168s
found 1 low severity vulnerability
run `npm audit fix` to fix them, or `npm audit` for details
Third time's a charm and it worked fine! :+1: :smile:
As I said, perhaps that's expected and/or documented somewhere (and I missed it) but perhaps it's somehow worth making it a little more friendly for the uninitiated? :smile:
Hi @JedMeister and thanks for the analysis, thorough and correct.
The debugging journey you describe is the same I had while trying to fix #3397.
Over time, I discovered that in order to execute npm audit on Etherpad I had to cd into /src, generate a package-lock.json and ensure I was using npm >= 6.
The problem is that I have repeated this dance so many times while working on fixing #3397 for 1.7 that I ended up desensitized to the poor user experience. Thanks for bringing this up again.
There are some issues at play here:
-
Etherpad conflates "developer mindset" and "user mindset". The official way of installing it basically consists of running a script that creates a symlink, installs all the dependencies (also the -dev ones) and finally runs the program.
-
Until #3396 (opened by @RalfJung on the same day of the ticket about the security vulnerabilites) the startup script also modified
package.json, because modernnpmversions changed their default behaviour. So I reformatted package.json (1, 2, 3) in order to minimize the eventual diff, and finally removed altogheter the saving step (c4918efc1bb2). -
Doing this, we also stopped generating the
package-lock.json, while previously users on newer npm versions would generate it. But at least a requirements file was no longer modified while running a program.
I am not satisfied with the current behaviour. There are some intricacies wrt how plugins are installed that I would like to study a bit more before rolling out another solution, but any ideas about how to improve this is welcome (even just in the documentation).
Great thanks @muxator - IMO, if nothing else it'd be worth adding an additional note to spell out what you need to do to run npm audit.
One way to do that would be to capture the output of the npm command (I'm assuming that's where it comes from?!) and alter it to explicitly to include cd src.
This is a little dirty (and completely untested) but assuming that the message comes from npm's stdout (on line 103), substituting something like this should do the trick:
output=$(npm install --no-save --loglevel warn)
echo $output | sed s"|\`npm audit|\`cd src \&\& npm audit|g"
This should transform this message:
run `npm audit fix` to fix them, or `npm audit` for details
into this message:
run `cd src && npm audit fix` to fix them, or `cd src && npm audit` for details
Better still would be to work out which directory the command is being run from and dynamically note the correct relative path to the src directory rather than just guessing (or perhaps just provide the absolute path?).
Hi, these days, running
/etherpad/src$ npm audit fix
on my system in results in
53 vulnerabilities (22 moderate, 27 high, 4 critical)
... that don't get fixed. I tried deleting node_modules, package-lock.json, npm install. Adding "--force" breaks Etherpad, is there anything else that can be done to improve this? ... Or is it something to ignore? Seems connected to the npm 6.14.18 package bundled for voodoo reasons that go beyond my understanding 😄
(my setup):
Etherpad 1.9.3 (latest) on Linux $ npm --version 10.2.0 $ node --version v18.18.0
Hi, these days, running
/etherpad/src$ npm audit fix
on my system in results in
53 vulnerabilities (22 moderate, 27 high, 4 critical)
... that don't get fixed. I tried deleting node_modules, package-lock.json, npm install. Adding "--force" breaks Etherpad, is there anything else that can be done to improve this? ... Or is it something to ignore? Seems connected to the npm 6.14.18 package bundled for voodoo reasons that go beyond my understanding 😄
(my setup):
Etherpad 1.9.3 (latest) on Linux $ npm --version 10.2.0 $ node --version v18.18.0
The problem is that most of the high and critical vulnerabilities are related to npm in version 6. @webzwo0i began a migration to npm version 10. But he doesn't seem to have time in the last two months. I am currently working alone at this project and try to update all the dependencies. Unfortunately this is mostly non trivial and especially the socket.io library is very hard to patch. That said if you or someone you know is good at JavaScript and Node and can help me I really appreciate any review and am here to review pull requests.
Force was never a good idea. As the note applies it updates everything to a non vulnerable state even though there are breaking changes involved.
@SamTV12345 - I feel your pain. I'd offer to assist, but my Javascript/Node is (extremely) minimal - think entry level at best. Good luck with it though and please feel free to ping me if you'd like me to test anything.
@SamTV12345 - I feel your pain. I'd offer to assist, but my Javascript/Node is (extremely) minimal - think entry level at best. Good luck with it though and please feel free to ping me if you'd like me to test anything.
@JedMeister With Etherpad 2.x.x we use pnpm instead of npm. So the days of security flaws, breaking lock files are gone. Enjoy Etherpad :)