
What happens when packages go bad? - jaffathecake
https://jakearchibald.com/2018/when-packages-go-bad/
======
perpetualcrayon
I say force the new maintainer to fork and then leave a note in your README
that the currently maintained version is (here).

This way anyone who decides to trust the new maintainer will be able to act as
a "canary in the coal mine", notifying others if they run into issues. This
also delays the gratification to the new maintainer. If they're truly
malicious they'll need to spend maybe months / years maintaining the code /
fixing bugs until they'll be able to hit pay dirt. I think most malicious devs
will not want to pay this price.

EDIT: This would also act as a window for (a) folks to find other alternatives
for their projects, and (b) inspire folks to build alternative options.

I think the willingness to fork over access to widely used packages isn't just
a reflection on your desire to move on from the project, but it also reflects
your blatant disregard of the thousands, maybe millions, of people who depend
on what you've built.

~~~
ATsch
The problem here is that often, there's not just the github repo, but also the
non-namespaced language package manager, e.g. npm, pypi. You'd have to
transfer that at some point. I'm also unsure how you can notify your users...
I have not looked at the readme of some dependencies for years.

~~~
perpetualcrayon
I'd say force a fork there too. It's not difficult to switch to a new package
once you find it and know the URL. I say force each user (whether it's end
user or library maintainer) to switch manually to the new maintainer's fork of
your project.

"I have not looked at the readme...". Maybe this will create a market for a
new type of project. The one that lets folks know the status of the packages
they use in their project.

~~~
mcguire
jquery, jquery-forked, new-jquery, forked-jquery, my-jquery, this-is-the-real-
jquery, potato-headed-rat-bastard-jquery, ...

~~~
Klathmon
npm has scoped packages, so you could make @mcguire/jQuery and I could make
@klathmon/jQuery

------
slededit
As a C++ developer I can’t imagine 1700 dependencies in a relatively new code
base. What are all those libraries doing?

~~~
GrumpyNl
This is why, this package is downloaded over a million times a week, all it
does is trim a string.
[https://www.npmjs.com/package/trim](https://www.npmjs.com/package/trim) Can
you imagine you need to depend on a external library for a trim function. Dont
get me starting about the security issues.

~~~
krapp
The problem here isn't depending on an external library for a trim function --
all it does is wrap string.replace, so minimal if any non-native functionality
is actually being provided.

The problem is that _something this basic is considered a complete library._
If you know regex you could write this on your coffee break. If you don't, you
could look it up and _still_ write in on your coffee break. If you want trim
and do anything else with a string, you need _another dependency tree._

This is not even really a problem with javascript lacking a standard library,
so much as a problem with the accepted practices of the javascript community.

~~~
robocat
> you could write this in your coffee break

When the trim library was needed, you likely also needed to support IE8.

But IE8 has a bug where \s doesn't match a non-breaking whitespace \u00a0 -
[http://www.nivas.hr/blog/2012/01/19/non-breaking-white-
space...](http://www.nivas.hr/blog/2012/01/19/non-breaking-white-space-in-
internet-explorer-8-bug-and-how-to-fix-it/)

And you need to decide whether you polyfill or ponyfill the function.

Yes you can theoretically do a trivial function in your break. With real
browsers in practice you will often find your trivial function just isn't
trivial.

~~~
krapp
>With real browsers in practice you will often find your trivial function just
isn't trivial.

But the string trim package mentioned above _is_ that trivial.

------
canadev
> It feels like it has a small attack surface, yet we use over 1700 packages.
> We only have 49 direct dependencies, so the vast majority of these are
> dependencies of dependencies of dependencies etc etc. The web app itself
> doesn't use a lot of third party code, so most of these packages are part of
> the build system.

Wow. Small attack surface with 1700 dependencies. What a hard concept to
swallow.

~~~
blattimwind
"We only have 49 direct dependencies"

~~~
randallsquared
Yeah, I work in a bunch of node.js codebases, and 49 deps seems pretty high,
unless they're including development environment deps.

~~~
untog
Presumably they are, since he talks about the possibility of developer
machines being attacked.

~~~
randallsquared
Well, regular dependencies get installed on developer machines as well, so I'm
not sure that follows.

~~~
untog
Well why _wouldn 't_ he be including them in a conversation that includes
developer machines?

------
lozenge
Commit your dependencies and don't update them. The chances of your site
actually exposing a security issue or bug that comes from one of your
dependencies is near zero, unless it's an actual security-relevant dependency
(sanitize-html, etc).

~~~
bfred_it
That's one way to bloat your repo.

There's no reason to commit your dependencies if your intent is security. Just
use the lock file. The packages won't change on npm and you'll always get the
same version for all sub-dependencies.

~~~
izacus
Doesn't JavaScript world know anything like Java Maven proxy servers? Which
retrieve artifacts on first lookup and cache them forever?

~~~
leipert
Well, the Java World is not free from it's problems when it comes to
dependencies: [https://blog.autsoft.hu/a-confusing-
dependency/](https://blog.autsoft.hu/a-confusing-dependency/)

Personally I do not understand why Java libraries which are binary blobs are
not targeted more often.

~~~
purple_ducks
> Java libraries which are binary blobs

Java libraries are JAR -> Java Archives. You can unzip them and there is JVM
bytecode inside which can be decompiled. Not really binary blobs.

------
dblotsky
Lock the dependencies: checksums, lock file, “=“ versions, whatever.

Even better, store them yourself: cache, mirror, zips in the repo, whatever.

This won’t protect you from an initial hack, but it means that if the
dependency was good when you got it, it will stay good.

~~~
eeZah7Ux
No. People deploying code must be able to manage vulnerabilities in
dependencies by updating them.

~~~
danShumway
Are you sure you're thinking about this from a Javascript perspective?

Vendoring dependencies on a Node project doesn't make it easier or harder for
me to update those dependencies later. I run the same commands from the
command line either way. It also doesn't make it harder for me to update
dependencies of dependencies either -- quite the opposite; I wouldn't advise
people to do this, but in an emergency if my dependencies are being tracked
via source control rather than fresh-downloaded on every install, I can make
security tweaks or change their dependencies, and those changes will actually
stick between installs.

Even on a website, vendoring my dependencies doesn't mean my dependencies need
to be a single blob -- I can still have a dependency deployed as a separately
updatable file.

Is there a specific scenario you're thinking of where vendoring a JS
dependency would prevent someone from updating it?

------
menzoic
Mirror dependencies and lock them down...

------
hartator
No real solution in there. Running a hacked package time to time is just rthe
cost of doing business.

