Live data from Hacker News

Npm Audit: broken by design?

overreacted.io

221–230 of 268 posts

Re: Npm Audit: broken by design?

#221

Earlier quoted context omitted.

I get it, JS is a weird language, but simple things like "is number" are still easy enough to do in JS, especially, when ints and floats are all just "number" in JS: function is_number(val) { return typeof val === "number"; } With a function that easily written, no one should have any excuse to depend on a third-party dependency for it.

But the code you posted is not what the code in this package does. If all you need is the code that you posted, then you should absolutely use that.

> not what the code in this package does

Here's `is-number` (https://github.com/jonschlinkert/is-number/blob/master/index...):

    module.exports = function(num) {
      if (typeof num === 'number') {
        return num - num === 0;
      }
      if (typeof num === 'string' && num.trim() !== '') {
        return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
      }
      return false;
    };

Care to explain why these 5 lines of code need to be a package? To me, having something so simple be a package by itself is absurd.

Re: Npm Audit: broken by design?

#222
post #2

This is a general problem with many security scanning tools, and when a security team is empowered to give deadlines to fix any issue they report, leads to much frustration and poor relations in teams. Imagine if you had 3 days to fix the regex DoS issue shown there, screw your release freeze and your current sprint plans, and you have the real working environment in some companies. I've also heard reports of people…

This is actively going on where I work. Granted, it’s a financial company, so they take security pretty serious. During our last release, we had to go through 3 different teams, all doing different security scans.

One if them is scanning all your dependencies, and its so frustrating. Because that team obviously has no idea what any of the dependencies do or how they’re being used. All they see is a red flag, and tell you to fix it. Good luck when they tell you this days before a release, and a week after the code is frozen. They’ll just block your release without a second thought.

Funnily, in our last release, some of our NPM packages were flagged as a risk, obviously without explanation. The thing was, these packages where dependencies of another package. Obviously we can’t go around updating open source code, just because the security team in our company told us.

Re: Npm Audit: broken by design?

#223
post #30

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…

Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?

There's lots of writing about monorepos these days, and they're quite common in public projects though usually at a smaller scale (ex. React is a monorepo, so is Babel and VSCode).

While complicated, in my experience the tooling to get the same productivity from hundreds of separate repos is at least as complicated and generally discourages folks from contributing to codebases outside their own.

Our monorepo encourages a collective velocity culture where everyone is pushing every project forward. If you upgrade React or Node, fix a security issue, or implement an optimization, the hundreds of apps are all improved at the same time. It's harder for one team to "leap forward" in terms of tech stack quickly, but at the same time it's far less likely we end up with hundreds of outdated or abandoned codebases since everyone is collectively improving the repo together.

For example I've rarely seen a single engineer upgrade a thousand separate projects across a thousand git repos with complex nested dependencies very successfully, but that happens every day in our monorepo.

Re: Npm Audit: broken by design?

#224

Earlier quoted context omitted.

But the code you posted is not what the code in this package does. If all you need is the code that you posted, then you should absolutely use that.

> not what the code in this package does Here's `is-number` ( https://github.com/jonschlinkert/is-number/blob/master/index... ): module.exports = function(num) { if (typeof num === 'number') { return num - num === 0; } if (typeof num === 'string' && num.trim() !== '') { return Number.isFinite ? Number.isFinite(+num) : isFinite(+num); } return false; }; Care to explain why these 5 lines of code need to be a package? T…

Note that there’s a difference between “needs to be a package” and “needs to be used by everyone.” Nothing needs to be a package, because it’s always possible to copy paste code, regardless of how many lines it is.

Re: Npm Audit: broken by design?

#225
post #2

This is a general problem with many security scanning tools, and when a security team is empowered to give deadlines to fix any issue they report, leads to much frustration and poor relations in teams. Imagine if you had 3 days to fix the regex DoS issue shown there, screw your release freeze and your current sprint plans, and you have the real working environment in some companies. I've also heard reports of people…

This is actively going on where I work. Granted, it’s a financial company, so they take security pretty serious. During our last release, we had to go through 3 different teams, all doing different security scans. One if them is scanning all your dependencies, and its so frustrating. Because that team obviously has no idea what any of the dependencies do or how they’re being used. All they see is a red flag, and tell…

>Obviously we can’t go around updating open source code, just because the security team in our company told us.

This isn't obvious to me. Most open source projects accept contribution from others.

Re: Npm Audit: broken by design?

#226
post #219

Earlier quoted context omitted.

> Super broken, everything related to npm's package lock stuff is broken by design. I've been saying it for years now and it seems people still cling to blindly trusting what corporations say. Because this isn't true. Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. These Regex issues should be fixed, libraries should update to safe versions, thin…

> Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. I've been in the node scene since 0.10. That's around 10 years. My packages have billions of downloads annually. My viewpoint here carries the weight of hours of debug time and frustration and confused users of my code, as well as meeting and knowing the npm staff at the time quite personally, and…

Hope do you make your builds hermetic and reproducible without package locks?

Re: Npm Audit: broken by design?

#227
This is why something like living at head is important. If npm audit reports something you should just be able to upgrade to the latest version. Being stuck with old versions is not good. Sure a vulnerability might not effect you now, but what if someone on your team uses that dependency again in a way that ran be exploited, or what if a new vulnerability comes out that actually effects you. You will be stuck on an old version and have to struggle to update.

Re: Npm Audit: broken by design?

#228
It's really disappointing to hear an important member of the javascript community not maintaining their library and then blaming npm when people rightfully complain about it.

This is like getting mad at the guidebook for showing which plants are weeds when your neighbors complain that your unmaintained garden is full of weeds.

If Dan says "npm audit is a stain on the entire npm ecosystem", maybe it's safe to say that Create React App is a stain on the entire react ecosystem. The best time to maintain it was every single month of its existence because that's how you maintain software.

Facebook has abandoned Create React App. Dan stated that he intentionally does not maintain the project. Rather than complain about npm audit, they should give Create React App over to the community who actually use it instead of keeping it shambling along as a zombie with their name on it.

And if Facebook doesn't want to give it up, the best thing we can do as a community is to move on to any of the other great tools available that are actually maintained.

Re: Npm Audit: broken by design?

#229

Earlier quoted context omitted.

This is actively going on where I work. Granted, it’s a financial company, so they take security pretty serious. During our last release, we had to go through 3 different teams, all doing different security scans. One if them is scanning all your dependencies, and its so frustrating. Because that team obviously has no idea what any of the dependencies do or how they’re being used. All they see is a red flag, and tell…

>Obviously we can’t go around updating open source code, just because the security team in our company told us. This isn't obvious to me. Most open source projects accept contribution from others.

> This isn't obvious to me. Most open source projects accept contribution from others.

Of course they do, and I'm more than happy to help with open source projects. My point was that, we can't do it, just because a security review at my company says so. It's not just as simple as updating the version of the affected package, there's also testing involved, potentially fixing issues due to using a later version. This would almost be a full-time job.

Re: Npm Audit: broken by design?

#230
post #219

Earlier quoted context omitted.

> Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. I've been in the node scene since 0.10. That's around 10 years. My packages have billions of downloads annually. My viewpoint here carries the weight of hours of debug time and frustration and confused users of my code, as well as meeting and knowing the npm staff at the time quite personally, and…

Hope do you make your builds hermetic and reproducible without package locks?

Ha ha, our builds are not “hermetic and reproducible” with package locks. Why? Caching.
Post reply on HN