Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

Post reply on HN
Print view View original

191–200 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#191

Post by andrey_utkin »

fmajid wrote: post #85
correct_horse wrote: post #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 depend…

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

Gentoo's package management system has neat automatable way to handle package licenses. See https://www.gentoo.org/glep/glep-0023.html

Re: Always Review Your Dependencies, AGPL Edition

#192

Post by mcguire »

"I just finished writing a vastly simpler, attestation-free library which is less than one tenth the size (I will open source it soon - watch this space)."

...

"Even though I love Rust, I am terrified every time I look at the dependency graph of a typical Rust library: I usually see dozens of transitive dependencies written by Internet randos whom I have zero reason to trust."

I have some kind of point to this comment, but I'm trapped in a sudden feeling of professional malaise.

Re: Always Review Your Dependencies, AGPL Edition

#193

Post by vbezhenar »

jaredklewis wrote: post #95
iforgotpassword wrote: post #76

Earlier quoted context omitted.

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…

It’s slowly expanding, but JS has an anemic standard library. The node platform adds a little, but yo’re still miles away from a typical standard library like Java or python. If you want to have 0 dependencies, you will have to write a lot of code to do things that would just be a line or two in most other languages.

The problem is not with anemic standard library. The problem is with lack of commonly accepted set of libraries. Java is not so good. You can't even copy one stream to another in Java 8. There's no built-in DI. There's no built-in ORM. Even built-in logging is so bad that everyone uses something different. Hell, no built-in JSON in 2019. But there's set of community-adopted libraries and everyone's using them. You need more utility methods? There's Guava (and, sometimes, apache commons). There's no left-pad library. You need DI? There's Spring. You need ORM? There's Hibernate. You need logging? Well, here's some competition between logback and log4j and that's about it. And even that competition has plenty of adapters which allows to write library code that works fine with both.

So JS community should throw left-pad in the window and declare underscore.js as a library of choice, so every other library will depend on it and that's about it.

Re: Always Review Your Dependencies, AGPL Edition

#194

Post by ncmncm »

marcus_holmes wrote: post #176
ncmncm wrote: post #78

Earlier quoted context omitted.

It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observa…

hmm, I always assumed it's a single "heeby-jeeby" and therefore multiple "heeby-jeebies", because that's how English mostly does singular/plural. But the repetition in "heebie-jeebies" looks more appealing. Even if grammatically unlikely. I'm confused now. Is "heebie-jeebies" intrinsically plural (like "sheep"), and therefore the pluralisation doesn't matter? Is there even such a thing as a single "heeby-jeeby"?

I can confidently state that I have never sighted a lone heeby-jeeby in the wild.

Heebie-jeebies are best thought of as an affliction, like hives or bedbugs, characterized by shuddering and head-ducking.

My guess is it started as a euphemism for hebephrenia, an obsolete affliction associated with youthful anxiety.

Re: Always Review Your Dependencies, AGPL Edition

#195

Post by dwheeler »

robmccoll wrote: post #190

On the licensing front, one thing that has really helped me is adding a script to my build / CI process that scans every package I'm dependent on for a LICENSE / COPYING / etc. file and then runs through a set of dumb fingerprints to match on different licenses for a combined whitelist / blacklist approach. Packages with no recognized license file or license are rejected. Then it spits the licences out into a map[str…

I completely agree that you should run 1+ license checkers in your CI process, just like you should check anything else in your CI process that you care about.

In the CII Best Practices badge project we use both the "license_finder" program (which is an OSS tool) and the FOSSA service ( https://fossa.com/ ). Both examine the dependencies for licensing issues. While something could still slip through, it's much less likely, and more importantly we have a really good case for showing due diligence. I'm not a lawyer, but I do know that courts look very favorably on people who are demonstrably making an effort to meet their legal obligations. You're way less likely to have legal problems that way.

Re: Always Review Your Dependencies, AGPL Edition

#196

Post by Lammy »

marcus_holmes wrote: post #70
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…

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…

What are you using instead of Webpack? I have a very old personal project still using Webpack 2 and would love a simpler alternative that isn’t just downloading library dist files and checking them in to my project repo. I don’t even need babel or minification or any of that, just simple dependency version management and fetching.

Re: Always Review Your Dependencies, AGPL Edition

#197

Post by mcguire »

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…

Does Maven Central also require machine-checkable proofs of security?

Re: Always Review Your Dependencies, AGPL Edition

#198

Post by aseipp »

dependenttypes wrote: post #165
grammarxcore wrote: post #145

Earlier quoted context omitted.

I ran into a speed issue last year messing around with Go RSA keys. Turns out it's an open bug. Even though fixes have been made (see links in the thread), it's not a global fix and Go ciphers can be absysmally slow. https://github.com/golang/go/issues/20058 The recommended fix is to use a library like this one. However, that means your containers blow up with complicated dependency trees so it's not really a good so…

I don't know if using gmp for RSA is a good idea. I am pretty sure that gmp would open you to side channel attacks due to its operations not being constant time.

GMP has constant time functions for the relevant primitives you'd need to implement RSA (notably, constant-time/space modular power functionality). You'll probably still fuck it up completely anyway if you're doing it yourself, but not because of that.

Re: Always Review Your Dependencies, AGPL Edition

#199

Post by sagichmal »

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…

The opposite of this is true.

Re: Always Review Your Dependencies, AGPL Edition

#200

Post by paulmd »

vemv wrote: post #182

> It started off poorly when I noticed some Brown M&M's: despite being a library, it was logging messages to stdout In many language ecosystems, logging to stdout tends to be the right thing to do in a lib as it does not impose any specific choice of logging implementation. One always can recapture stdout and route it through one's logging solution of choice; doing something analog with an extraneous logging library…

logging to stdout prevents any sort of systematic parsing or handling of stack traces, package names, or error levels, cause people are going to dump whatever shit they personally find most useful onto stdout and everyone's going to use a different format. That is a far far more "analog" solution than using any logging API... or even multiple ad-hoc logging APIs.

The idiomatic solution is to have a standardized facade like SLF4J and then behind the scenes the "end user" (final developer writing the application) can choose their own logging backend to drive the facade.

The slightly less idiomatic way is that everybody does their own thing and then you use bridge libraries to hijack all of the various logging APIs and redirect them through SLF4J or through your logging backend of choice.

Post reply on HN