Always Review Your Dependencies, AGPL Edition • Hacker News Board

Re: Always Review Your Dependencies, AGPL Edition

#111

Post by CuriousSkeptic » Mon, Jan 06, 2020, 12:01 PM UTC

jlg23 wrote: post #60

atoav wrote: 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

Or a factory method returning a singleton as a null object

Re: Always Review Your Dependencies, AGPL Edition

#112

Post by jefftk » Mon, Jan 06, 2020, 12:02 PM UTC

lmm wrote: post #98

cygned wrote: 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…

Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk. In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amaze…

This protects you against licences you don't expect, but not against malicious or subverted dependencies.

Since a dependency can generally do anything your application has privileges for, widely depended-on libraries are an attractive target. A cattle approach means more dependencies, and it being easier for new ones to sneak in.

Re: Always Review Your Dependencies, AGPL Edition

#113

Post by cannam » Mon, Jan 06, 2020, 12:03 PM UTC

valvar wrote: post #53

pbhjpbhj wrote: post #28

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.

> are familiar with his most famous phrase

In some cases, possibly, via Asterix: https://www.everythingasterix.com/latin-jokes-content/2015/4...

Re: Always Review Your Dependencies, AGPL Edition

#114

Post by pas » Mon, Jan 06, 2020, 12:03 PM UTC

krapp wrote: post #94

pas wrote: post #87

Earlier quoted context omitted.

Modern JS is TypeScript. Also Yarn is very handy. (Fast, simple, correct.) If you need leftPad, maybe just "vendor" it manually.

Modern JS is the current ECMAScript standard. Typescript is not "modern JS", any more than Coffeescript was, any more than the compile-to-js language that will probably replace it in a week. You're confusing the tool for the language the tool operates on, akin to claiming modern C++ is Visual Studio.

Not using TS means leaving a lot of useful tools on the floor.

The ECMAScript standardization is process is invaluable, after all TS builds upon it. But TS provides a saner subset (and adds a very productive type system), without that I wouldn't touch "modern" JS even with a stick.

Re: Always Review Your Dependencies, AGPL Edition

#115

Post by enriquto » Mon, Jan 06, 2020, 12:03 PM UTC

lmm wrote: post #98

cygned wrote: 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…

Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk. In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amaze…

> Dependencies are cattle, not pets.

It depends on your context. Sometimes, dependencies are not pets, but weights on your airplane.

Re: Always Review Your Dependencies, AGPL Edition

#116

Post by anton_gogolev » Mon, Jan 06, 2020, 12:04 PM UTC

lmm wrote: post #98

cygned wrote: 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…

Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk. In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amaze…

> There's nothing wrong with having zillions of them...

There's nothing wrong until something goes wrong an now you're royally screwed. With zillion dependencies you are at a mercy of zillion maintainers, and none of them has any obligation to you. They can break backwards compatibility in patch releases, introduce subtle behavior changes, steer the project in an unexpected direction or abandon it altogether.

Re: Always Review Your Dependencies, AGPL Edition

#117

Post by C14L » Mon, Jan 06, 2020, 12:07 PM UTC

herpderperator wrote: post #16

When this webpage loads, it briefly flashes in plaintext before loading CSS - at least in Chrome. This is unusual since it has the CSS stylesheet in the head which I thought would block until it's fully loaded. Does anyone know what's going on with that?

Only blocks by default, doesn't.

Re: Always Review Your Dependencies, AGPL Edition

#118

Post by robbya » Mon, Jan 06, 2020, 12:09 PM UTC

generationP wrote: post #107

> Aside: this is why I don't like to accept pull requests that move code around. Even if the new code organization is better, it's usually not worth the time it takes to ensure the pull request isn't doing anything extra. This sounds like a solvable problem no one has bothered to solve. We need an analogue of diff highlighting for move-around changes, ideally one that decomposes a changeset into the coarsest block pa…

For changes that are a pure file rename 'git mv' tracks those pretty cleanly. Anything beyond that... I don't know of any good tooling either.

Re: Always Review Your Dependencies, AGPL Edition

#119

Post by robbya » Mon, Jan 06, 2020, 12:13 PM UTC

sansnomme wrote: post #4

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…

Agreed. I found this project helpful for automating dependency checks: https://github.com/pivotal/LicenseFinder

I actually played around with turning it into a GitHub action for further usability improvement, although it needs more work: https://github.com/ralexander-phi/license_approval

Re: Always Review Your Dependencies, AGPL Edition

#120

Post by seemslegit » Mon, Jan 06, 2020, 12:18 PM UTC

cygned wrote: 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…

Seems like negative comments about npm are getting shadowbanned here, so let's try again: npm-based software engineering culture is utterly irresponsible and should be viewed as a liability for both a company and its users.