
Major bank accidentally published a private package to the public NPM Registry - edward
https://twitter.com/seldo/status/1105153287718723584
======
Ndymium
A recent experience tells me this is a very easy mistake to do, though. I was
using Yarn to publish a package to an internal package repository (so setting
`private: true` was not an option). I did not know at the time that Yarn would
not honor `publishConfig` in the `package.json` file, and it would also ignore
the package's organisation set in `.yarnrc` (which is used to direct read
operations to the internal repository).

What it did was ask me to "log in" (there was no prompt to sign up), which I
did with our internal credentials. It also asked for an email address, which
in retrospect was foolish of me to provide, but that was the only indicator
that something was not right. It did not tell me where I would be publishing
to.

When it was done it said the package was published. I checked the internal
repository and it was not there. Instantly felt that horrible feeling in my
stomach that everyone knows. I went to npmjs.com and found out that it had
helpfully created an account with the internal credentials I provided, the
credentials that were given in a prompt that said "npm login".

What saved me was that the package was inside an organisation ("@foo/bar") and
those are not free on NPM, so the package was not published, even though Yarn
said so. The user account was created, though, so I had to recycle that
password and send email to NPM support to get the account deleted (there is no
way to delete your account yourself, sadly).

The moral of this post is that when I saw this tweet I did not laugh at the
company's foolishness in publishing internal code on NPM, because I almost did
that myself and saw how easy the mistake is to make. (Of course, the rest of
the tweet with the DMCA stuff is foolishness.)

~~~
rounce
> What saved me was that the package was inside an organisation ("@foo/bar")
> and those are not free on NPM...

(Public) Orgs _are_ free on NPM (at least nowdays) so maybe even that wouldn't
have saved you.

~~~
Ndymium
Then I am not sure what did prevent publishing, but it was not published.

~~~
joshuacc
npm orgs are free, but the org has to be created before you can publish to an
org's scope.

------
seldo
This really isn't news, folks. It happens every week. I was just grumpy this
morning.

~~~
omouse
If this happens often, perhaps the user interface for npm publish needs to
change? I mean, that's the only thing I can see mitigating this, with like a
nice dialog that says "hey, are you REALLY REALLY sure and have you consulted
lawyers on this???"

Or something to that effect. Or maybe companies can just pony up for NPM
Enterprise which fits their use case.

~~~
vvoyer
No alert box ever will save you from doing the biggest mistakes, most people
don’t read them.

~~~
ivan_gammel
Just compare this to publication to Maven Central - you’ll never publish there
by accident exactly because there are significant barriers. Public NPM repo
should not be that easily accessible for upload.

~~~
kbenson
At some points in a language and its package management system's lifetime,
reducing barriers to publishing are one of the best things that can be done to
increase packages and fill out the ecosystem, and drive utility and adoption.

Later, once you have most needs filled by packages, and a good number of
enterprise users, more control is beneficial. Companies appreciate it, and
single users are willing to jump through an extra hoop or two much of the time
because the rest of the ecosystem is so useful that it's not worth switching
languages.

I think it's unlikely that a system will move from one style to another
without an event causing them to reevaluate their prior choices. More likely,
multiple events. This has already happened with NPM for other choices they
made in the past, such as letting package namespaces be claimed by new people
after someone gives it up, and whether releases are immutable, IIRC.

~~~
lugg
Please don't think this way.

This is such a solvable problem.

Doesn't package.json have an is private repo flag? Why not just respect that?

Why does everyone everyone in this thread think a pop up is the solution?

Pop ups are a code smell. They mean your application does not correctly match
user intent with the action so badly you had to specifically get your user to
tell you what they meant to do. Did you mean to do that? Always, yes.
Otherwise, undo.

The only place did you mean makes sense is in Google search results.

Why is public and private publish anywhere near each other? Why are they even
on the same page?

Stop drawing boundaries around nouns.

~~~
madeofpalk
> Doesn't package.json have an is private repo flag? Why not just respect
> that?

npm _does_ reflect that flag. If you set private in package.json, npm won't
publish it publicly. From docs:

> private

> If you set "private": true in your package.json, then npm will refuse to
> publish it.

> This is a way to prevent accidental publication of private repositories. If
> you would like to ensure that a given package is only ever published to a
> specific registry (for example, an internal registry), then use the
> publishConfig dictionary described below to override the registry config
> param at publish-time.

~~~
bigiain
Perhaps inverting the logic there might be worth considering?

Make it so you have to explicitly go in and mark your package.json as public
before npm will publish it, and have the default be private?

I don't have _too_ much sympathy for the bank here - it's in npm's best
interest to make it easy to publish leftpad.js easily <snarky smirk> \- and
that probably should be their default stance.

The bank should be responsible for ensuring their "banking grade security"
includes not accidentally publishing their source code to public repos. (How
much would you bet against there being instances exactly like this where the
publication vector was GitHub instead of npm? How much would you bet against
this exact code being on a public git repo somewhere as well? How many public
code hosting services should be expected to change their business models
because some bank gets uptight after they've fucked up?)

~~~
BoorishBears
What's impressive to me is you (and so many others) being charitable enough to
assume that the original developer didn't intentionally publish this package.

Some bank developer (or more likely, some underpaid contractor) wants to share
something between projects and doesn't want the hassle of proper channels, or
just doesn't care enough and thinks "I'll publish this, who will ever find
it?".

Years later someone stumbles upon it, maybe they don't even know who did it,
"NPM why do you have our code?!?!?!?!"

This is the most likely scenario once you consider this was a bank. In which
case there's nothing NPM could do. No warning would have changed their intent,
they knew what they were signing up for.

~~~
ivan_gammel
If there’s enough friction, no one would bother publishing to public repo
instead of setting up private Nexus instance, which is quite easy. And it’s
quite possible that the leak could happen on early stage of CI setup for that
project (private flag removed, but wrong login used). It’s a mistake very easy
to make: “private” flag is just not an appropriate tool for private CI.

------
ahallock
Slightly off topic, but my experience with lawyers and technology has been
mostly discouraging. For example, one lawyer wanted to sue a client of ours
for using an open-source JS dropdown menu that we were also using--he said
they stole our code. He was also concerned that we were letting people 'View
Source' our web pages and stealing our IP.

~~~
linsomniac
That reminds me of a hosting client I used to have, which we got a DMCA
takedown notice for: "They are using our software without a license." I
replied: "They are a local reputable University, have you tried contacting
them?" "I wasn't able to get ahold of them." "You weren't able to get ahold of
a _UNIVERSITY_?!?" "Well, I didn't really try. I'm a subcontractor, in another
country, and can't afford to make phone calls about it."

I had also reached out to our client contact. They contacted the CMS company,
provided them with the license information, and then switched to another CMS.

------
ronilan
Next tweet: “We sell a thing that prevents this kind of mistake ...”

Just sayin.

~~~
orblivion
How would you prefer free software be funded? :-P

~~~
ronilan
We are a little tounge in cheek here, but I’ll take this question seriously.
While it is great that NPM can develop new and more reliable products, is
would also greatly benefit them and everyone else, if enerprises of certain
size or stature would be required, legaly or regutoraly, to pay for software
they already use. So say you are a bank, and there is a list of regulations
that you have to comply with, so here is a new one. FTC (or California law
makers) can figure out the mechanics and JP Morgan will write the check. Then
NPM will already have a solid foundation to build on, some indie will have a
windfall, and the big software guys might say hell yes, that’s a new business
model. That’s what I’d prefer, but no one but you is asking me ;)

~~~
shados
As mentioned already, it wasn't that long ago when big corps like banks didn't
touch open source or free stuff with a stick. People who worked at those big
banks, companies like Oracle, etc, back then will be able to tell you that
almost everything was built in-house.

The problem NPM solves isn't a particularly interesting or challenging problem
to solve if you don't try to solve it at scale. They'd just build their own.
Then for the couple of packages that are hard to replicate, they'd find a way
to sign some papers to get access to the code and push it to their own
registry. For everything else they'd just rewrite it from scratch. Short of
things like React, it's not all that hard for places with the resources of
these big corps to rewrite bundlers, web servers, and utility libraries.

------
gauravphoenix
This is more common than we think. At RedLock[1], we found several docker
images which aren't supposed to be public.

[1] [https://redlock.io/blog/docker-repo-public-
access](https://redlock.io/blog/docker-repo-public-access)

~~~
aboutruby
And on a little website known as Github there is a lot more :) (and Google
Search stays the #1 reliable source of private data followed by AWS S3).

------
koolba
Here’s a pro tip: _Enable 2FA for your NPM account_

Not only do you get additional security for 2FA, you also get a prompt for the
TOTP pin that makes you question what and where you’re publishing.

~~~
landr0id
Even with this, people are dumb. It's probably not a case of "we didn't
realize we were publishing to" and instead a case of "some dev didn't realize
this was a bad idea".

~~~
pbhjpbhj
>some dev didn't realize

Surely in a bank, when publishing, the decisions aren't down to a single dev.
Either many people made a mistake together or many people made lots of small
mistakes separately that added up to one big one??

FWIW, I don't know, I'm a small time potter, just how I imagine things happen
in banks (I do know a couple of devs who work/worked for banks).

~~~
jjeaff
You are going to have a ton of technical barriers in place if you are going to
stop everyone from publishing to one of the many and varied code repos out
there.

~~~
burfog
An air gap will stop innocent mistakes and outsiders.

~~~
smackfu
And kill dev productivity.

~~~
burfog
None of that productivity matters if the company dies due to being hacked
into.

You might not even know that this happened. Mysteriously, a clone company pops
up, or a competitor seems to know all your contract negotiations and
customers.

Another possibility is that a lawsuit over data leakage takes out the company.
Sometimes reputation alone can kill a company.

BTW, it's really pessimistic to suggest that an air gap would kill
productivity. It isn't that hard to physically transfer files from the
computer at your left to the computer at your right. The disconnected network
can have copies of popular software repositories, including for your OS to get
updates.

~~~
tracker1
If your systems are so weak that seeing code puts you at risk, you have other
issues.

------
born2discover
It took them no less than 3 years to actually notice... Holy moly! I wonder
what package that is... Just out of curiosity...

~~~
beager
You'd think it's like, some proprietary trading algorithm, but in reality it's
probably their own implementation of left-pad.

~~~
taarushv
It was a react package.

Source:
[https://twitter.com/seldo/status/1105157348560007168?s=09](https://twitter.com/seldo/status/1105157348560007168?s=09)

~~~
skissane
Just guessing here, but probably something like some front-end UI components
for their internet banking system. Which then probably got simplified to
"someone has posted the source code to our internet banking system on the
Internet"

------
redshat
I work at a large bank and a majority (if not 98.98989%) of the employees are
morons. This doesn't surprise me one bit. I hope we find out which bank it is,
I would bet money on it being the one I am employed at. Banks do security
through obscurity and worry more about COMPLIANCE than they do actual security
and that is a fact.

~~~
mstade
I also work at one of the top tier banks but I’m not quite as doom and gloom
as you. (Maybe I’m one of the 1.01011% – finally!)

It’s certainly true that some security practices within our organization seems
more like security theater than anything else, but overall I think they have
pretty reasonable standards and requirements set. It is very true though that
the culture is almost entirely focused on compliance more than anything else,
so there’re few proactive measures taken by teams. Lord knows no team I’ve
ever seen outside of security wants to budget for it. Maybe it’s a damned if
you, damned if you don’t kind of situation. If you don’t set compliance
regulations you’ll get no security (move fast and break things, yay!) but if
you do you end up with people ticking boxes saying “the thing is secure and
stuff yo” and then play the blame game when it isn’t.

My feeling though, having worked with top tier banks in the financial industry
for the last 8 years or so, is that more people are competent than not, but
process stifles creativity and drive a lot of the time. It’s a very special
kind of environment to work in.

------
vortico
"Ignorance" is not having knowledge about a certain field. Everyone has it.

"Stupidity" is having ignorance about a field but pretending not to.

These lawyers may have 7 years of law school education, but they are still
"stupid".

~~~
elliekelly
Option C: Easy "billable hours"

------
mnutt
To partially mitigate this issue, I scope all private packages to @corp-
internal/ _, then use a .npmrc directive to push all packages in @corp-
internal / to packagecloud.io. The @corp/_ scope is used for open source
packages, @corp-internal scope does not exist on the public npm registry so no
chance of config issues causing mistaken pushes.

~~~
koolba
Do you own @corp-internal or is it otherwise blacklisted?

What stops someone from creating that account and owning that org?

~~~
mnutt
Yeah, it is registered but empty and has no real users so nobody can publish
packages there.

------
tuxracer
[https://docs.npmjs.com/files/package.json#private](https://docs.npmjs.com/files/package.json#private)
anyone hoping to avoid the same fate

------
mstade
Anyone know what bank? Or what package?

------
FlowNote
I did my part in preventing such outcomes because I own goldmansachs

npm install goldmansachs

------
jhare
Tell them it's a $35 fee for every erroneous publish. They understand fees.

~~~
koolba
They wouldn’t believe it’s real at $35.

Maybe $35/byte. Then the lawyers could haggle, get it reduced to $35/non-white
space byte, and feel like they accomplished something.

------
alkonaut
What is the risk/problem with this, assuming the bank didn't have anything
sensitive or security critical? (If they had Keys, personal info etc in their
source then _that 's_ the problem isn't it?)

If someone finds a module of BankX's boring backend code, what is the
risk/problem for the bank?

~~~
uberswe
Some companies like to practice security through obscurity. So you might be
worried that someone trying to exploit the system would have an easier time
testing effective exploits.

Another thing is the code itself, you don't want competitors seeing your
implementation if you feel that it gives your company an advantage over
others. There may be data structures or algorithms that are internal company
knowledge only and defined in the code.

~~~
jhare
Hide the embarrassingly ugly, also.

------
z3t4
Why not just take it down? What do you need a lawyer for ? Isnt there an
option for deleting your own packages ?

~~~
ahallock
You would think so, but perhaps they didn't have the credentials.

~~~
benatkin
They never contacted a human at npm, they just went straight over their heads.

~~~
kevin_thibedeau
Npm should have a forced arbitration clause for anyone posting code under US
jurisdiction. Then they can pull a procedural power play.

~~~
bachmeier
That wouldn't help. The bank's accusing them of publishing stolen code.

~~~
kevin_thibedeau
The bank, as a corporate entity, posted the disputed code. It doesn't matter
that the right hand doesn't know what the left hand did.

------
wolco
Is this client side code? Unless this is internal wouldn't it be available
when visiting there website?

~~~
nwsm
Probably doesn't matter to their legal team. All code is company IP so they
don't want it posted anywhere unnecessarily.

Tweet thread says it's a react packaged which means it's probably usually
transpiled and minified, so not technically available in its original form in
its distributed application.

------
AlexTWithBeard
In our company access to public repos is blocked.

I was upset about it when it was introduced, but now I start to see the
point...

~~~
tln
You can't install from npm?

~~~
woutr_be
Most likeley they have an internal npm repository that mirrors all the
packages, only available through a proxy. At least that's how it works where I
work, other than having to set up your proxy settings once, there's no
noticable difference.

~~~
orthoxerox
That's the best practice that should really be implemented everywhere. The
proxy can even filter the packages by license, so you don't put AGPL code into
your e-banking solution by negligence.

~~~
burfog
It is part of best practice. You really should have an air gap. Consider the
problem of malware connecting out and then giving an attacker a VPN into your
network.

------
linsomniac
"Now I get to spend money on a lawyer to explain this to them."

------
snazzycalynx
This is annoying. Maybe npm can consider adding a confirmation prompt to
publish if a new package is about to be created. Not sure if it'd prevented
such ignorance though.

------
orian
So, they're free riding on NPM and threatening it with lawyers. Seems legit.

------
Halluxfboy009
I hope he send them the bill for his lawyer.

------
gautamdivgi
As long as the code doesn’t contain credentials and hard coded urls it should
be fine. Probably just regular old logic

------
ionforce
Is there a thing that's like "by using this service you put your work in the
public domain" kinda thing?

~~~
icebraining
No, npm only says you give them a license to allow them to serve the package
to users; other than that, you're free to license it however you want.

~~~
Wowfunhappy
So the bank shouldn't be able to send DMCA takedown notices, right? Because
they granted npm the license to redistribute the package.

~~~
lgeorget
I think they can argue that the code is their property and that the employee
that published it on NPM had no mandate from the company to do so. So it's
effectively "stolen code" in a sense, just as if the employee had done it to
harm the company on purpose.

------
rdlecler1
This should be renamed: Employee at major bank accidentally published a
private package to the public NPM registry.

------
schappim
Which bank?

------
jordache
it's probably just a data visualizer component.

------
JustSomeNobody
Abused the DMCA also.

SMH.

~~~
syntheticcdo
How is this DMCA abuse? A copyright owner is requesting that a site that has
safe harbor protection remove an unauthorized copyrighted work. The employee
that originally created the unauthorized package may no longer work for the
bank, unable to be identified, or doesn't have the credentials anymore.

~~~
cm2187
Does the fact that the bank distributed the material in the first place change
the situation?

~~~
bdamm
No. The Bank's intent is what matters, not the intent or actions of a single
employee.

~~~
AWildC182
At some point the corporation needs to take responsibility for what its actors
do... You can't just say everything good that happens is because the corp is
awesome and everything bad that happens is because that one guy did something
stupid so it's all his fault and the corp is still awesome.

~~~
icebraining
IANAL, but yeah, under the imputation doctrine, the company is usually
responsible for the actions of its employees. There is a small exception, but
it generally only applies when the employee goes fully rogue, harming the
company itself in the process, but here it seems to be a mistake, so not
applicable, AFAIUI.

Still, that doesn't mean they can be bound by a license granted by an
unauthorized employee. I think at most they would have to pay damages, if any.

------
symlinkk
I hate how there's no official way to run your own private NPM registry. So
you have to either pay NPM or resort to third party solutions like verdaccio.
It's such an obvious money grab by the NPM devs.

~~~
zackbloom
They're running a business. They offer an inordinate amount of service totally
free to millions of developers, and they make their actual client open-source
for your pleasure. Is your argument they also have to go to the trouble of
making their infrastructure easily self-hosted? How would they make the money
to pay the lawyers to respond to the very legal threat this tweet is about
without revenue?

~~~
iooi
Please, it's arbitrary to run a private PyPi repository, all you need is a web
server and a certain folder structure. If you want, you can even host
everything on a private S3 and use a tiny Nginx configuration to authenticate
the requests on behalf of pip [1].

Private npm repositories are an entirely different beast, and like GP
mentions, there is no great option here.

[1] [https://www.guido.nyc/pypi-s3/](https://www.guido.nyc/pypi-s3/)

~~~
JdeBP
Potential users should be aware that the quoting in the shell commands on that
page is faulty and requires attention.

~~~
iooi
Can you give an example? Not sure what you're referring to.

