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

201–210 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#201

Post by paulmd »

ones_and_zeros wrote: post #188

Johnny come lately but is that true of the AGPL, that merely linking to agpl code infects your code? No modification to the agpl code needed to trigger the clause? What is the point of having a license like that? Trolling?

Yes, that is generally how copyleft (GPL) software works. Linking against it confers a requirement that your source also be distributed under a compatible license. This is why it's called a "viral" license.

AGPL was intended to close the SaaS gap in copyleft software. Essentially, prior copyleft provisions don't kick in if you never distribute the software itself, so if you only offer network interaction with the software you have no duty to redistribute.

AGPL is intended to restore the freedom of end users to have access to the source of the software they interact with, even if it lives on someone else's computer. As with all copyleft software, it does this by restricting the rights of the developers of the software (to keep their source proprietary).

As always, it is the old philosophical split between MIT/BSD style licenses and GPL style licenses. MIT/BSD provide you with complete freedom, including the freedom to use that library and keep your source closed. GPL is intended to prevent that and to build a common base of software on which further things can be built.

(there is also Lesser GPL license, which only kicks in for modifications to the library itself. So if you write something that uses a LGPL library, you don't have to give away source for the larger program as a whole, just the LGPL program and any modifications you made to it. This is essentially removing the "viral" copyleft provisions.)

Re: Always Review Your Dependencies, AGPL Edition

#202

Post by grammarxcore »

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.

I abandoned the project because I couldn't find a reasonable solution using standard Go libs that worked in a reasonable timeframe. The bottleneck is this function.

math/big.addMulVVW

There was some work on it recently.

https://go-review.googlesource.com/q/addMulVVW

But I feel like this issue might have been ignored.

https://go-review.googlesource.com/c/go/+/164966

It might be addressed in Go 1.14 (although it's been marked as Backlog since I last looked at that issue).

https://github.com/golang/go/issues/32492

Point being Go, like OP of this thread suggests, has some issues. This is, to me, a critical flaw preventing my teams from using Go as a primary web language. It is both consistently faster and consistently timed to make an external call to, say, gpg2 to generate a key than it is to use the opengpg lib that relies on math/big. That's nuts.

Re: Always Review Your Dependencies, AGPL Edition

#203

Post by vmchale »

damnyou wrote: post #186
vmchale wrote: post #172

Earlier quoted context omitted.

It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.

Only incompatible versions though — Rust dedups dependencies up to semver compatibility. I think that's the right balance. clap 3 is and should be treated as a totally different package from clap 2.

It's not as bad as cabal back in the day.

Nonetheless I have run into the diamond dependency problem in practice. Their solution is unprincipled and there's no way to turn off the default behavior.

Re: Always Review Your Dependencies, AGPL Edition

#204

Post by vmchale »

matheusmoreira wrote: post #169
baby wrote: post #151

Earlier quoted context omitted.

Rust is on this path as well, the small standard library pretty much forces people into using a ton of tiny dependencies. Compiling a rust project is exactly like using npm and seeing a never ending list of deps

The underlying problem is the lack of curation. Micro-dependencies that are widely used and have been reviewed for quality should be promoted to a group of standard packages. They'd still be dependencies like any other but they'd be officially maintained and installed by default. Another problem with npm: every package gets its own copy of its dependencies. Not sure if Rust does that.

> every package gets its own copy of its dependencies. Not sure if Rust does that.

It does something halfway in between, which is still a security liability.

Re: Always Review Your Dependencies, AGPL Edition

#205

Post by damnyou »

vmchale wrote: post #203
damnyou wrote: post #186

Earlier quoted context omitted.

Only incompatible versions though — Rust dedups dependencies up to semver compatibility. I think that's the right balance. clap 3 is and should be treated as a totally different package from clap 2.

It's not as bad as cabal back in the day. Nonetheless I have run into the diamond dependency problem in practice. Their solution is unprincipled and there's no way to turn off the default behavior.

Do you mean passing a struct from e.g. clap 2 into clap 3? Yeah that won't work directly, nor should it in my opinion. If it is frequently required, projects can and should provide a compatibility layer which does any necessary conversions.

Re: Always Review Your Dependencies, AGPL Edition

#206

Post by ljm »

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…

They both have flaws. NPM due to the cascading mass of transient dependencies; go (historically) due to pulling dependencies from the master branch of a repo. All of those can change from underneath you.

In any case you can’t avoid proper auditing and pen-testing. Even if your app code is rock solid, it doesn’t mean your infrastructure is safe. Or even your office building or the data centre serving the code. Or your employees and their credentials.

All it takes is a decision to use mongodb or redis without auth and to expose the ports to the internet, and the most secure runtime in the world won’t save you then.

Or a bit of social engineering so the attacker is making perfectly legit requests in your perfectly secured app.

Re: Always Review Your Dependencies, AGPL Edition

#207

Post by darkarmani »

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…

> what you need is good tools to manage them in bulk

How do you manage reputation and relationships in bulk? There are transactional costs here. Dependencies created by maintainers with impeccable reputations are a much smaller risk than arbitrary dependencies created by arbitrary maintainers.

Re: Always Review Your Dependencies, AGPL Edition

#208

Post by tomlagier »

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…

I don't think anyone thinks it's perfectly fine (well, maybe newer people in the industry). I just don't think anyone sees a viable alternative.

By adopting any semblance of a modern front-end stack, you're going to be pulling in a huge dependency tree. So, your choices are:

A) Don't do modern front-end development. This, despite being very popular with the HN crowd, is a challenging option. Losing the power of popular frameworks makes it difficult to recruit new developers, slows down developer velocity, and can cause tech debt to accrue more quickly.

B) Validate every dependency. For a skilled security reviewer, this may be possible. For an average developer however, reviewing thousands of dependencies is unlikely to be a good use of time. There are some improvements, automated tools that can be run, but the unfortunate reality is that the NPM attack surface is massive and I don't know of any techniques for producing any truly reliable security assessment.

C) Depend only on packages that you trust and trust them to validate their dependencies. Obviously, if this transitive trust breaks down at any layer then a vulnerability is introduced.

In practice, I've only ever seen individuals and companies do C. I think if there was some tooling around B, that would be the best option. I see a lot of room for disruption here - if there was a way to assign trust to a dependency and then a package-manager level construct that would only allow trusted dependencies to be installed, that might work.

I think the ship has sailed on A.

Re: Always Review Your Dependencies, AGPL Edition

#209

Post by flanbiscuit »

Lammy wrote: post #196
marcus_holmes wrote: post #70

Earlier quoted context omitted.

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.

I switched to Rollup for a project and liking it so far, also less dependencies:

Here's a comparison of popular bundlers using a visualization tool I found online:

Webpack - https://npm.anvaka.com/#/view/2d/webpack

Parcel - https://npm.anvaka.com/#/view/2d/parcel

Rollup - https://npm.anvaka.com/#/view/2d/rollup

Granted this only covers the initial package for each of these, there are usually a bunch of extra plugins or cli packages that you'll need to work with each of these but I also found the dependency tree of each of the added Rollup plugins to be less than the other 2.

here's rollup-plugin-babel: https://npm.anvaka.com/#/view/2d/rollup-plugin-babel

Re: Always Review Your Dependencies, AGPL Edition

#210

Post by [deleted] »

atoav wrote: post #160
sime2009 wrote: post #140

Earlier quoted context omitted.

The risk profiles of the examples you gave are not comparable to that of most software projects. Most software projects are harmless if they crash. No one is hurt. Software projects which do risk injury and dead, for example embedded medical, get a lot more engineering and QA.

While you are certainly right that certain fields are more deadly than others, less direct things like loosing personal pictures of someone, leaking someones unencrypted medical data, getting some abstract score wrong, etc. can seriously impact your users lifes. And even the more security critical fields constantly do things wrong. When you can change the workings of an insulin pump that is in someone elses body remo…

[deleted]
Post reply on HN