Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

81–90 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#81
post #2

That's the hidden cost of npm, cargo, pip, et. Al. The other one is IMO akin to overweight. Try to modernize a mid-sized project after one or two years and cry when you see the dependency graph. Ceterum censeo go inferior est.

If you define the "modernization" as mindlessly switching to a trending framework or library, the cost is inevitable even without package managers.

You don't need to mindlessly switch to a trending framework or library.

Try upgrading typescript to the latest version. I think that's a fair definition of "modernisation" and something which should be benign.

But now all of a sudden you have to upgrade every dependency to the latest version - or write your own .d.ts files - since they're typically written to the current library version - typescript version combination.

Re: Always Review Your Dependencies, AGPL Edition

#82
post #60
post #42

Earlier quoted context omitted.

> I'd think the comparison goes the other way around :) Only in the Software industry. This is however not normal: * Mechanical Engineering: Hobbyist bridge vs. professional Bridge – which one should you be able to trust more to carry you? * Electrical Engineering: Hobbyist wall wart vs. professional wall wart – which one should you be able to trust more not to burn your house down? * Medical Treatment: Hobbyist vs.…

IMHO, lots of software development resembles crafting much more than engineering and we have put so much effort into sounding smart that we are now training craftsmen that sound like scientists but are not necessarily good at their craft... "I used the Singleton Pattern!" "Awesome, you learned about global variables!" blank stare

"All patterns are anti-patterns."

Re: Always Review Your Dependencies, AGPL Edition

#83
post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

No, you are basically right, but the number of nodes in the dependency tree doesn't really mean that you really have to review all of those. Usually you end up with a big basket of actual dependent projects, and with some versions for them (which leads to the big explosion of the number of nodes in the dep tree).

Naturally it should be easy to specify a whitelist of licenses. (Of course then one has to decide whether to trust the package.json-s.)

That said, security review is hard for any ecosystem. Go probably has inherent advantages compared to the JS ecosystem, simply by virtue of being younger, having a real standard library, being more focused (no browser vs nodeJS issues) etc.

PS: there are projects that aim to do collaborative audit/review for Rust ( https://github.com/crev-dev/cargo-crev ) there should be something like that for the JS world. also there's the NPM "report vulnerability" feature.

Re: Always Review Your Dependencies, AGPL Edition

#84
post #53

Earlier quoted context omitted.

[flagged]

I'm not sure if you are being ironic or not, but Cato the Elder is an extremely famous roman figure. I think most educated people, especially on HN, are familiar with his most famous phrase even if it is not in the most common formulation.

Well I've heard of him. But I suspect you greatly overestimate the importance of dead Romans to contemporary programmers.

It is no doubt possible to be a good, English speaking programmer, without knowing anything much about the Roman empire and its inhabitants, if you come from the east Asia for instance.

Even for those from the West, there are cultures which do not rate Ancient Rome as so significant that it is necessary for an educated person to be familiar with Cato the Elder's most famous phrase, whatever it may be.

Re: Always Review Your Dependencies, AGPL Edition

#85

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 depend…

There are over 200 OSI-certified open source licenses, and no automatable way to handle them.

Re: Always Review Your Dependencies, AGPL Edition

#86
post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

similarly, I refuse to use JS libs that have ridiculous dependency trees (most annoyingly, including Webpack, which means my Vue setup is more interesting than it needs to be). I was explaining why to a friend, and it appears that no-one takes this threat seriously, not even in secure/financial apps. Like you, I wonder if I'm missing something obvious. Why does the npm dependency trust nightmare give me the screaming…

Because even in 2020, even in " secure/financial apps" most programmers have security and lic legality as a secondary (or even forth level) concerns, they just want to "make something cool"

They play lip service to it being secure, and/or license compliant

Re: Always Review Your Dependencies, AGPL Edition

#87
post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whet…

Modern JS is TypeScript.

Also Yarn is very handy. (Fast, simple, correct.)

If you need leftPad, maybe just "vendor" it manually.

Re: Always Review Your Dependencies, AGPL Edition

#88

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review the source code of the Go compiler and standard libraries. Well... I have reviewed the Go runtime, after I ran into a bug in it... And that's one of the reasons I no longer use Go unless forced to. That thing is ugly under the covers. There is seriously quite a…

> That thing is ugly under the covers.

Was the code you looked at in Go 1.5 and above? Is it cleaner in 1.4? They used automated tools to convert the C code into Go for 1.5.

Re: Always Review Your Dependencies, AGPL Edition

#89

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

This is a reason for Debian to exists.

Licenses cannot be reviewed automatically in a reliable way. Debian developers review the licenses and store them in a machine-parsable file.

Re: Always Review Your Dependencies, AGPL Edition

#90
post #85

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 depend…

There are over 200 OSI-certified open source licenses, and no automatable way to handle them.

I (and I'm sure many others) would gladly take an option to provide a whitelist of acceptable licenses.
Post reply on HN