21–30 of 99 posts
Earlier quoted context omitted.
> biting a lot of people In what sense? I doubt there are many apps (if any) out there that actually have a vulnerability here, because it's unlikely that a web app out there is going to be passing random user input to a mac address package.
Add to that that cssnano is unlikely to even be present in deployed code, it’s a build tool.
Earlier quoted context omitted.
It's amazing that something like cssnano would have a dependency on getting MAC addresses. WTF?
npm was a mistake
Are you sure you understand the issue?
Earlier quoted context omitted.
npm was a mistake
NPM doesn't change anything here. the same issue would exist if you could only vendor dependencies. Are you sure you understand the issue?
Edit: Answer to “always_good”:
If a toddler shoots himself with a handgun, we can say that his mistake was pulling the trigger.
While technically correct, it’s not addressing the real issue, that is, how did the toddler get hold of the gun in the first place?
The current version was released 3 years ago.
The code is small and straightforward.
Using exec("cat x " + userdata) to read a file in any language should immediately drive any developer nuts.
Apparently, nobody ever looked at the code. Or maybe some people did, but never reported it. Pretty sure some companies did, fixed it in their closed local fork and never notified the author nor contributed their fix back.
This is really scary, and really bad for the trustworthiness of open-source software.
Earlier quoted context omitted.
NPM doesn't change anything here. the same issue would exist if you could only vendor dependencies. Are you sure you understand the issue?
Javascript was a mistake Edit: Answer to “always_good”: If a toddler shoots himself with a handgun, we can say that his mistake was pulling the trigger. While technically correct, it’s not addressing the real issue, that is, how did the toddler get hold of the gun in the first place?
Passing user input into arbitrary shell commands is the mistake.
Good examples of amateur criticism that plagues our field, though.
I think that it is much more relevant that the node community does do many micro packages, that it makes so much nose to look at the quality of pulled in packages.
I recently pulled down a web app (Zulip) the packages.json expands to almost 1400 npm packages. How is any human going to look at all that. And apparently it is "normal" for an npm project to have that many dependencies.
Too me this is madness. It is impossible to know the quality of all those packages.
Earlier quoted context omitted.
It's amazing that something like cssnano would have a dependency on getting MAC addresses. WTF?
I maintain a package that has an indirect dep to macaddress because of UUID generation. UUID v2 is generated from Mac address + timestamp. My package only generates uuid v4 (fully random) and even if it was, the uuid dep doesn't expose the vulnerable argument. As such it isn't vulnerable. But the dep is still there. This isn't surprising at all tbh.
crypto = require('crypto');
function uuid4() {
const bytes = crypto.randomBytes(16);
bytes[6] = (bytes[6] & 0x0f) | 0x40;
bytes[8] = (bytes[8] & 0x3f) | 0x80;
return bytes.toString('hex').match(/(.{8})(.{4})(.{4})(.{4})(.{12})/).slice(1).join('-');
}Earlier quoted context omitted.
NPM doesn't change anything here. the same issue would exist if you could only vendor dependencies. Are you sure you understand the issue?
Javascript was a mistake Edit: Answer to “always_good”: If a toddler shoots himself with a handgun, we can say that his mistake was pulling the trigger. While technically correct, it’s not addressing the real issue, that is, how did the toddler get hold of the gun in the first place?