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

Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

medium.com

Post reply on HN
Print view View original

261–270 of 412 posts

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#261

Post by withinboredom »

eitland wrote: post #252
withinboredom wrote: post #244

Earlier quoted context omitted.

We do this. I had to work on a greenfield project and it used a ton of libs that weren’t in our repo. It was so annoying to have a list of repos to add to the in-house list, then discover things didn’t work, so now we need these. It literally added weeks of man-hours to the project, per day.

> It literally added weeks of man-hours to the project, per day. Can you explain what exactly you mean here, because the way I read it realistic time estimates for the projects grew by weeks pr day which probably means - I misread - you wrote something you didn't mean Anyways it sounds like something was way off and I have worked on some projects with Maven and other systems.

Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#262

Post by beermonster »

iam-TJ wrote: post #200
beermonster wrote: post #172

Earlier quoted context omitted.

I think image signing support (or at least was) is not as good as it can be. It would be nice if more images were signed by publishers and verification performed by default. Even then, that only gives you a stronger indication that the image hasn't been altered since it was signed by the image author at any point after it being signed. However it is not a guarantee that the source produced the binary content. It's al…

Approximately 25,000 of just over 30,000 source packages are now reproducible builds - generating over 80,000 binary packages. See the graphic on the page you linked to: https://tests.reproducible-builds.org/debian/unstable/amd64/...

I did also find this https://isdebianreproducibleyet.com/

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#263

Post by ritchiea »

austincheney wrote: post #260
ritchiea wrote: post #230

Earlier quoted context omitted.

Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.

It isn't about writing your own package manager. At least start with not using every package offered by NPM or dependencies that do. If you cannot attest to every package in your dependency tree you have failed dependency management.

Ok so you're going to argue to an engineering manager or product manager that you need a day or days to do a full code audit of each external package you use? Or write your own library instead? That's, if anything, more unrealistic than just writing your own package manager.

Do you actually get to do this wherever you work? Honestly it would be great to have the luxury of that kind of patience and time to invest in my work. But it's universally unrealistic in my experience.

This is not at all a question of "what would be the ideal or perfect scenario." This is a question of what's pragmatic and politically accomplishable in most work environments.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#264

Post by eitland »

withinboredom wrote: post #261
eitland wrote: post #252

Earlier quoted context omitted.

> It literally added weeks of man-hours to the project, per day. Can you explain what exactly you mean here, because the way I read it realistic time estimates for the projects grew by weeks pr day which probably means - I misread - you wrote something you didn't mean Anyways it sounds like something was way off and I have worked on some projects with Maven and other systems.

Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.

OK, so again not Mavens fault but an utterly insane bureaucracy?

Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#265

Post by oauea »

withinboredom wrote: post #261
eitland wrote: post #252

Earlier quoted context omitted.

> It literally added weeks of man-hours to the project, per day. Can you explain what exactly you mean here, because the way I read it realistic time estimates for the projects grew by weeks pr day which probably means - I misread - you wrote something you didn't mean Anyways it sounds like something was way off and I have worked on some projects with Maven and other systems.

Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.

Yes, vetting everything takes a LOT of time. Regardless of the language, package manager, etc.

We (small shop) don't vet the code of all of our dependencies, since we simply don't have the manpower. But we do run nexus to have the guarantee of version pinning. So something that is fine today will be fine in 5 years.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#266

Post by wyc »

Here's the application called deptrust I submitted to the Mozilla Builders program (didn't get in :P) to address this problem space before I had to focus more on my current job. Please let me know if there are any collaborators who would like to work on this together someday!

https://docs.google.com/document/d/1EW6uSZB0_D0qZuDSGuxujuVE...

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#267

Post by _ph_ »

Spooky23 wrote: post #193
Diggsey wrote: post #177

Earlier quoted context omitted.

I disagree: the problem is not that package managers make things easy, it's just that several of them are poorly designed. The fact that pip/npm/gem etc. look for packages in a fallback location if not found in the private repository is a terrible design flaw. One which not all package managers have. For example, when you add a cargo dependency from a private registry, you have to specify the registry that the depend…

It's a little bit of both. Maybe "problem" is the wrong word. It's a risk that you need to understand and account for. If you're running a bank, it's an existential impact that you must avoid. If you're running a message board, it's not. Look at what happened when the "left-pad" function disappeared from npm a few years ago. IIRC, it broke react. The downside of package managers like this is that many people have no…

Indeed. They make it far to tempting to just pull in a dependency, even if it is not really needed. The worst case of this are one-function packages in npm. And of course whenever you pull in a dependency, that might in a cascade pull in more dependencies. Somteimes the same package is pulled in several times, even in different versions.

What looks elegant as a concept "we just have a graph of dependencies and automatically pull that in" quickly becomes an unmaintainable nightmare and consequently into a huge attack vector.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#268

Post by GrinningFool »

ritchiea wrote: post #230
austincheney wrote: post #227

Earlier quoted context omitted.

> No one gets fired for using npm Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code.

Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.

Currently, managing dependencies correctly by vetting them with each and every version bump is huge amount of overhead and it grows with each dependency pulled in. The way we as an industry have been handling it has largely been to keep going like we don't need to.

It's going to keep getting worse until a) developers and project managers realize doing inherently unsafe things is bad and b) they have the resources to give the additional ongoing levels of scrutiny. I'm not hopeful that this will happen at large in the industry, though I know it _is_ happening within individual companies and projects.

I'm sure we'll mitigate the damage to some extent by making package managers smarter and implementing finer-grained permissions. That will improve the situation over time, but it also takes us in the wrong direction by allowing us to forget that when we're shipping dependencies, we ultimately own their behavior.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#269

Post by avereveard »

eitland wrote: post #264
withinboredom wrote: post #261

Earlier quoted context omitted.

Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.

OK, so again not Mavens fault but an utterly insane bureaucracy? Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?

I agree on "not maven fault" but I don't find that much bureaucracy insane, for one changing dependencies on a mature java project doesn't happen that often, and for another knowing licensing, possible patent violation and a scan against a known vulnerabilities database is not a bad thing to do and it's normal for it to take some time as it passes hand between different people, after all you don't want devs working on licensing and you don't want to waste legals just to run a package trough vuln scans software.

beside, companies that care usually also have a database of previously cleared packages, so one can reduce one own work/delays by picking from the approved deps list.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#270

Post by itake »

ex_amazon_sde wrote: post #186
trishankkarthik wrote: post #152

Earlier quoted context omitted.

I work in this area. This is not a supply chain attack. This is a typosquatting "attack" people keep rediscovering every year or two. I know, because I wrote an as yet unpublished paper on safely pulling packages from private and public repos.

This is not correct. Installing packages only from a trusted (and signed) source protects against typosquatting, misread or confusing package names and many other risks.

forgive my naivety, but my understanding of the NPM and rubygems ecosystem is open source packages host their source code on github/gitlab. The source code is super easy to view. Often times, the author will use tags or branches dedicated to specific versions of the code.

For distribution, js and ruby use rubygems and npm to host packages. If a developer wants to verify that the package hosted on npm is the same code being displayed and worked on by contributors on github, they need to pull down both sets of code and then either run a checksum or compare line by line to verify the code matches up. Malware or a nefarious package owner could slip in unexpected code into the package before shipping it to the package host, leaving the github version without the changes. No typo-squatting needed.

Just because some form of the source code is published to Github, doesn't mean its the same code that is hosted on npm or ruby gems.

Post reply on HN