Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

21–30 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#21
post #6

I would love to have this guy write my security sensitive software.

I used to work with a guy that would review every line of our projects node modules. He’d find issues all the time, so there’s no way he wasn’t pay attention. He also managed to be productive with writing his features. Having that guy on the team was amazing, I have no idea what motivated him to do such tedious work, but he seemed to love it...

With a bit of electronics background this feels like the difference between a hobbyist and a professional.

Most programmers feel like hobbyists to me, in their YOLO-approach. Your software might ruin someones day, their life or maybe even end up killing people and more people should take that thing seriously. The way your collegue worked should be the norm.

Re: Always Review Your Dependencies, AGPL Edition

#22
It seems like this is a good opportunity for Github to warn you if

a) a PR would merge a new dependency with an incompatible license to yours

and

b) allow you to filter out projects based on licenses from search results. in general most of us would prefer to avoid being tainted by GPL code and it'd be great to hide it on the site entirely.

Re: Always Review Your Dependencies, AGPL Edition

#23

> I repeat the above recursively on transitive dependencies as many times as necessary. I also repeat the cursory code review any time I upgrade a dependency. If this guy has to work on a "modern" frontend project, he's gonna review dependencies until the heat death of the universe.

Okay, but let's be clear about why we're putting "modern" in quotes. Sure, pulling in half of NPM is a common way to do things currently, but it's also a very painful way to do things, currently. A "modern" dependency tree is going to cause you tons of pain, starting with having to configure your dependency tree and getting worse from there. If you use a few, small, effective dependencies, you can reasonably do a cursory code review with every upgrade, and there are other major benefits.

Don't let some drive to be "modern" cause you to use libraries that make things more difficult than using vanilla JS.

Re: Always Review Your Dependencies, AGPL Edition

#24

> I repeat the above recursively on transitive dependencies as many times as necessary. I also repeat the cursory code review any time I upgrade a dependency. If this guy has to work on a "modern" frontend project, he's gonna review dependencies until the heat death of the universe.

What this guy does sounds like a machine-doable job.

At our company we use whitesource to scan each and every build for these kind of license violations.

Re: Always Review Your Dependencies, AGPL Edition

#25
post #17

> I repeat the above recursively on transitive dependencies as many times as necessary. I also repeat the cursory code review any time I upgrade a dependency. If this guy has to work on a "modern" frontend project, he's gonna review dependencies until the heat death of the universe.

But doesn‘t that say more about modern leftpaddable frontend frameworks than about the author?

[deleted]

Re: Always Review Your Dependencies, AGPL Edition

#26

> I repeat the above recursively on transitive dependencies as many times as necessary. I also repeat the cursory code review any time I upgrade a dependency. If this guy has to work on a "modern" frontend project, he's gonna review dependencies until the heat death of the universe.

Nearly spat out my cereal, thanks. Funny because accurate. As a relatively new node dev, this is what keeps me awake at night.

Re: Always Review Your Dependencies, AGPL Edition

#27
post #21

Earlier quoted context omitted.

I used to work with a guy that would review every line of our projects node modules. He’d find issues all the time, so there’s no way he wasn’t pay attention. He also managed to be productive with writing his features. Having that guy on the team was amazing, I have no idea what motivated him to do such tedious work, but he seemed to love it...

With a bit of electronics background this feels like the difference between a hobbyist and a professional. Most programmers feel like hobbyists to me, in their YOLO-approach. Your software might ruin someones day, their life or maybe even end up killing people and more people should take that thing seriously. The way your collegue worked should be the norm.

I'd think the comparison goes the other way around :). Hobbyists care enough to do things right even if it's not in the short-term interest. Professionals, judging by all the advice I read on-line, are supposed to focus on delivering value - which is usually measured short-term, and not aligned with doing things right. It's that attitude that makes most companies care little to none about security. Bringing in tons of dependencies in order to increase velocity and implement user-facing features faster is what I see advertised as archetype of a professional in this industry.

Re: Always Review Your Dependencies, AGPL Edition

#29
Why don't npm-like package managers have settings for licenses in applications (as opposed to libraries)? Settings like "no AGPL" or "no copyleft dependencies" would allow easy vendoring with modifications. This (disabled by default) feature might break some proprietary code, but if it does, that indicates you were not following copyright law prior.

Obviously this doesn't solve the general quality problem with dependencies that the author notes, but it fixes some licensing issues.

Re: Always Review Your Dependencies, AGPL Edition

#30
post #20

It's always been weird to me how Microsoft invests so much in making JavaScript easy to develop and maintain with TypeScript but does so little to make it safe, the one thing JS needs is a standard library by Microsoft (or similar, e.g, Google) that we can trust, aiming to significantly reduce the number of dubious-origin dependencies of every JS project (on node and the browser)

Yeah, remember the left-pad incident? It took until ECMAScript 2017 to make such a simple function part of the standard library. Things are slowly getting better, but JS is still rather lacking compared to "batteries included" languages like PHP and Python.

This comes up pretty often, what would you like to see in such a standard library? I consider the libraries included in Node pretty extensive these days.
Post reply on HN