Thanks for the feedback @emilis-tm!
Just want to confirm that I haven’t seen a single error in the last 24h. I have run my script a few times both yesterday and today.
Thank you for the confirmation! We appreciate the feedback and glad to know the recent changes have helped!
This is still happening to us, albeit far less frequently. We’ve seen a couple of one-off instances since this change went in back in January, however today we’ve seen a sharp increase.
Is this still an issue server side? Or is it an expected error that the CLI needs updated to more accurately convey?
This is still happening in our CI environment. The volume of false negatives this has introduced has degraded confidence in our CI pipeline and is making it difficult for me to convince my team that
npm audit is a valuable tool for us to continue using.
14:59:35 throw err; 14:59:35 ^ 14:59:35 npm ERR! code ENOAUDIT 14:59:35 npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.
Our CI environment is using
firstname.lastname@example.org, so we don’t have the latest
audit CLI; meaning that isn’t necessarily a 404 like you’d expect looking at the latest CLI source code. Let me know if there’s any more information I can provide to help get this resolved. This seems like a very promising tool and I’d like to see it reach its full potential despite these issues.
edit: also, status.npmjs.org suggests no issues at the current time
Also seeing this intermittently on local dev machines and CI (Concourse CI) with
email@example.com. Here are the logs:
0 info it worked if it ends with ok 1 verbose cli [ '/usr/local/Cellar/node/11.11.0/bin/node', 1 verbose cli '/usr/local/bin/npm', 1 verbose cli 'audit' ] 2 info using firstname.lastname@example.org 3 info using email@example.com 4 verbose npm-session e2849a2da393f6d3 5 http fetch POST 502 https://registry.npmjs.org/-/npm/v1/security/audits 9589ms 6 verbose stack Error: Your configured registry (https://registry.npmjs.org/) does not support audit requests, or the audit endpoint is temporarily unavailable. 6 verbose stack at Bluebird.all.spread.then.catch (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/lib/audit.js:201:18) 6 verbose stack at tryCatcher (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) 6 verbose stack at Promise._settlePromiseFromHandler (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31) 6 verbose stack at Promise._settlePromise (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18) 6 verbose stack at Promise._settlePromise0 (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10) 6 verbose stack at Promise._settlePromises (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:690:18) 6 verbose stack at _drainQueueStep (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:138:12) 6 verbose stack at _drainQueue (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:131:9) 6 verbose stack at Async._drainQueues (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:147:5) 6 verbose stack at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14) 6 verbose stack at processImmediate (timers.js:637:19) 7 verbose cwd /Users/sally/workspace/teachers 8 verbose Darwin 18.0.0 9 verbose argv "/usr/local/Cellar/node/11.11.0/bin/node" "/usr/local/bin/npm" "audit" 10 verbose node v11.11.0 11 verbose npm v6.9.0 12 error code ENOAUDIT 13 error audit Your configured registry (https://registry.npmjs.org/) does not support audit requests, or the audit endpoint is temporarily unavailable. 14 verbose exit [ 1, true ]
I’m sorry about that! I’m verifying with our team and will get back to you.
Can confirm we run into this issue regularly as well in our CI pipelines. Had the same pipeline running this morning all fine, in the afternoon it failed with the exact same error as above.
We are running these in the cloud on Azure DevOps, maybe it’s some rate limiting related thing from certain ip ranges?
you might want to disable audit on CI (
npm config set audit false or set
audit=false in your CI’s
Well i have that CI pipeline running daily for it’s sole purpose of checking whether any new vulnerabilities have been found since last check. So disabling it is not what i’m looking for, i want to run it reliable without false positives.
Basically i’m in the same boat as JordanForeman, it’s hard to convince people that npm audit is a valuable tool since currently the amount of false positivies (CI failing because of the described error) is to high.
But we, as a team and company, believe that it’s part of secure software development to keep track of any vulnerabilities and mitigate if needed.
Experiencing this issue also with our CI pipeline, through CircleCI.
I get this same error time to time, it disappear after some hours; then come back later and so on.
I’m in the same case as @rthewhite, we’re getting too much false-positives and we don’t have any feedback on what’s going on because it’s on npm side.