Hacker News new | past | comments | ask | show | jobs | submit login
Major bank accidentally published a private package to the public NPM Registry (twitter.com/seldo)
568 points by edward on March 11, 2019 | hide | past | favorite | 220 comments

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.)

This is bad design. I may have come close to doing this as well for the same reason. There is no reason why NPM should auto-register you when you attempt to publish (or auto-register when you attempt to sign in) other than to remove a few steps/friction to make it seem like a nice experience.

Explicit vs. Implicit : always choose explicit if accidents can cause people serious pain. npm login that is secretly npm "create account" is a serious anti-pattern. And npm publish -> npm login -> npm create account is a consequence of that.

It would make sense to print the registry before asking for the new version in `yarn publish`, so that you get a chance to double-check that the publish target is what you expect. Will open a PR for the 1.16, unless someone beats me to it :)

> 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.

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

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

Yeah, when I first started playing around with node I accidentally published one of my "hello world"-like apps to NPM's public registry. There was definitely no warning or indication of the severity of the action I was undertaking.

It's an easy mistake to make. What is concerning is that the bank didn't notice for three years... I feel like that should have been caught a lot sooner.

These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such human errors. And of course changes to this script have to be reviewed.

Also, a .rc file (package manager chosen by the team) with a private registry that refuses to publish unless done automatically by the pipeline set in the root of every project.

The only reason I find it understandable how it could happen at a major bank (these days, they should have a sizeable team that takes care of security measures like I described) is that this was 3 years ago. Publishing to private registries was relatively new back then, so people didn't have proper publishing workflows yet.

I mean... I guess mistakes can still happen. But on a scale of 1-10, I would find such a mistake far less excusable today considering the circumstances. Small, inexperienced team, maybe constant deadline pressure - more excusable. Duh...

> These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such human errors. And of course changes to this script have to be reviewed. > > Also, a .rc file (package manager chosen by the team) with a private registry that refuses to publish unless done automatically by the pipeline set in the root of every project.

This is how we do it. Publishing is locked down to specific service accounts, with credentials set up in a CI environment with locked down build configurations. Publishing to the internal registry is not possible unless you have these credentials, and you don’t. There’s a whole process for retrieving keys. Publishing to the internet isn’t possible due to a firewall just killing those requests dead. You could probably do it via a proxy, but you’d break your contract and probably be fired if not worse.

People complain about the locked down build configurations, until they need help at which point standard build configurations mean they actually get support, as opposed to “good luck; have fun!”

Source: I work for a major bank. (Presumably not the one this story is all about!)

Wouldn't `npm unpublish --force` revert this? If you provided an email you'd get a notification about a published package so you'd notice immediately even if you didn't at first.

It's not relevant to my post if it can be reverted. Once it's out there, it's out there. There are bots scouring all new GitHub commits for API tokens, I would not be surprised to see bots auto-downloading all new NPM packages.

For the original tweet's company, there was probably some kind of incompetency involved in not noticing that the code was public for years. But I can't comment on that further as I don't know the circumstances. I only wrote my anecdote about the accidental publishing side.

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

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.

I work at a major bank and for the US Army. Both of those organizations are hyper sensitive about security for good reasons. Unfortunately that hyper sensitivity often results in really bad decisions and gross misunderstanding of software.

Publishing software is not a security violation in greater than 98% of cases. The only valid exceptions are protections of trade secrets and cryptographic information.

I am not counting software with embedded credentials, embedded business data, or other bad practices. Those are security violations regardless of public exposure.

Trying to explain this to security sensitive organizations is painful. I am confident in the stupidity of this conversation as somebody who has been writing code for more than 20 years and passed the CISSP exam the first time back when it was a 250 question paper test.

I'm trying to understand your point. I agree with the basic premise that most pieces of code that end up not getting exposed are not sensitive, but building guardrails to ensure people who aren't security minded ask the right questions and get closer to 'default correct' ends up being a requirement in major banks/government organizations. The number of times someone has done something completely silly like include API keys in a public package or Git repo is reason enough to care. Being beholden on an external system being secure and up to standard ruins pretty much every category of a risk analysis, especially when you end up with gold like this article or the PHP PEAR hack.

Then there is always that part of the organization that isn't judicious about keeping packages up to date, and these kinds of package exposures expose their negligence.

Then there is the other piece of my systems being dependent on your systems in a sometimes inappropriate matter if precautions aren't taken. 'Oh I just added this dependency' is a quick way to an outage if rules aren't set.

> The number of times someone has done something completely silly like include API keys in a public package or Git repo is reason enough to care.

Agreed, but that is not a publication problem. That is a separation of concerns violation which indicates a host of other problems from the lack of code review to incomplete security testing to various ad hoc or integrity violations.

External systems have no bearing on the validity and completeness of your organizations internal security controls. It doesn't matter how incomplete, insecure, or unqualified NPM is to serve a given set of code. The problem isn't NPM or the publication to NPM. The problem is the contents that comprise the publication in question. A good security audit would ask why any certain content is available for publication in violation of internal policy regardless of what that content is.

For example if you accidentally publish to NPM code containing a bunch of user PII the problem is why PII was resident in the code in the first prior to publication. The fact that such PII is exposed is now a different second problem demanding a different resolution. You could make the argument that halting and regulating all publications would solve that problem. That is incorrect, because the PII is still exposed within your organization outside of a controlled environment and can still be leaked to the public by various other means.

> Then there is always that part of the organization that isn't judicious about keeping packages up to date, and these kinds of package exposures expose their negligence.

That is dependency management whether or not you own the packages in question. Dependencies need to be appropriately managed for a variety of security reasons. Exposing poor dependency management advertises a vulnerability, but the vulnerability is there anyways and a dedicated malicious attacker will exploit it the same either way.


The bottom line is that hiding your security problems by "not publishing" is not a valid security control. That is the dreaded security by obfuscation and it works both ways. By hiding the vulnerability you also hide the exploitation from visibility.

You could not have a default. Then in order for someone to publish to the public NPM, they'd have to enter the URL for the public NPM. Otherwise publish should fail.

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

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.

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.

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.

> 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.

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?)

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.

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.

I think open source tools should always default to sharing. If you're trying to keep things secret it should be up to you to keep them secret.

> it's in npm's best interest to make it easy to publish leftpad.js easily

That's what I was getting at above. It definitely was in NPM's best interest to do so. Depending on your definition of "easily", is it still in their interest to have it quite that easy? Perhaps a different default is in order now, as you suggest. Or perhaps it should even require a confirmation dialog on the terminal for the first public push? People will still use NPM at this point. Not having enough packages or a package for a specific functionality is hardly a problem for them any more.

They could just change it to `npm publish npm|url name` with some useful warnings. The name should be checked against package.name.

Then libraries could simply add an npm script for publishing.

    npm publish

    To publish a package to
    npm, you must enter:

      npm publish npm <package-name>

    To publish a package to
    another registry, you
    must enter:

      npm publish <url> <package-name>
Just as easy, just clearer.

cool, so now the developer that did this will just thoughtlessly type npm publish npm instead.

At the end of the day, there's only so much you can do. Really, a hammer shouldn't have a prompt on it confirming each hit. If it does, users will just instinctively press it and then a few months down the road they'll hit their thumb.

The npm docs also state that the "files" property of the package.json limits what gets installed if you install that package in another project.

Ever tried installing a local package via a file path? NPM just symlinks it into node_modules, causing issues because you suddenly have duplicated dependencies. Yarn does the same, btw.

I have given up any hope regarding npm/yarn acting sensible long ago.

> 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.

Not a rule. Do you really want undoable actions like "Delete" to just delete in a touch operated interface?

I disagree, there have been times a well-placed popup stopped me from accidentally doing something really stupid, other times there wasn't a popup and I ended up doing something stupid.

It doesn't necessarily have to be a pop up popup per say, but extra validation around dangerous actions is user friendly.

And of course there can always be an override for the extra validation in case it potentially screws up some people's workflows, but I'd make a user explicitly set the override, like the 'NoHostAuthenticationForLocalhost' option in ssh for example.

Popups only work if they Confirm button is not a button, but "enter this text exactly: I really want to publish this package to the whole wide world" and block copy-paste.

If the user hacks around that, it's their own fault.

If a pop up is required to prevent you doing something stupid the UX has already failed.

I don't think a popup solving a problem means it is solving the right problem in the right way.

I wasn't condoning popups. I was making a high level observation of package systems in general.

That said, I fully support a terminal level confirmation the first time something is pushed publicly in any package manager. It is absolutely the correct thing to do to add safeties to a process that is irreversible and can have negative consequences. Often enough, making anything public online is irreversible, and making something public that wasn't ever supposed to be can have negative consequences in many respects.

But what I was really thinking of when I was typing my original comment was moving to a system where someone actually approves new package publishing accounts and or some subset of package namespace requests. Systems that start without any sort of moderating or approval process seem to eventually settle on one. The reasons for this are numerous, from security to just keeping people from overwhelming the more common or sought after names and general sanity checks (does a system really need to allow separate packages for a term where one is singular and one is plural? Who does that help?).

npm publish already prevents you from publishing a package that has the private flag. They must not have had it set.

This is going to be cynical, but as far as I understand it people are looking for usability through vanity.

Why not install `com.facebook.react’? Reverse domain notation is remarkably elegant given our internet. You are not typing ‘npm i com.facebook.react’ so often that it’s a pain. You probably use ‘create-react-app’ which is even worse.

Instead, every language creates a new cash grab for common names. And made it worse. New namespaces, new squatting. I can publish ‘react-racket’ and do whatever I want behind the scenes with it.

Case in point: do you add coffeescript or coffee-script.

Why optimise for keystrokes in your term instead of stability for your client? Jesus fuck.

The JavaScript community is moving into the Enterprise and is discovering Java's good ideas from 1995


A whole quarter of a century, or perhaps half of the entire software industries lifetime, of exciting known security errors to look forward to!

BRB, off to hide all my bitcoin under my mattress...

> Why not install `com.facebook.react’?

That would be a bad idea, and it's not just brevity.

- If com.facebook.hr has previously been published, would it mean that facebook can never have a division named HR?

- Once a company goes belly up, the domain often ends up with squatters/spammers. Domains with published packages will sell for a lot more in the underground market - for pure exploitation of rights to publish a newer version.

- In the absence of validation, nothing stops anyone from publishing com.google.exploitlib. And domain validation is friction.

- Most publishers on npm may not have a domain.

And finally like someone mentioned below, npm already supports scoped packages. https://docs.npmjs.com/about-scopes

Regarding your concerns, some friction is necessary. Without friction I can skate, but I can't drive.

There's a little bit of movement happening in that direction in the npm world with scoped packages. E.g. babel moving all official packages to @babel. Storybook does it too. Doesn't even have to be much of a branding loss. FB could publish @react/react, @react/native, @react/eslint-config, @react/create-app, @react/prop-types, @react/dom... Most of the typing is happening in require/import not npm install, so there's some argument for not going the full java route.

Setting `private: true` to your package.json will prevent this from happening

setting `public:true` would solve this problem

But default should be public - it's an open source piece of software

What you're describing is consumer protection, but a company isn't a consumer. The bank responsible for their own actions.

No, the first step is to say you haven’t set a publish source. Your toolkit might generate that but you should also see that in code review.

It should not auto create accounts. Compared to Nuget. I find NPM absolutely scary to use because it’s unpredictable. (Personal opinion)

It would be good if there were a standard format for referencing private keys in code, like "pk_*". Then NPM could say,

> "it looks like your package might have a private key in file xyz.js on line 27. Please type "no it doesn't" into the box below if you're sure this is not the case".

Adding 'private: true' to the package.json prevents publishing to _any_ registry, including a corporate proxy. Adding a string or regex option for private that would only publish to matching registries may prevent issues like this.

I ask for regex only because our corp proxy binds to a random port reach time it runs so a static string wouldn't be flexible enough.

Why isn’t this a source URL?

Took a while for Ruby to get it but for the last 5 years you have default config for self-hosted sources whenever you make a new gem.

Of course, npm is unique in being privately funded. It doesn’t want you doing that.

Benefit of the doubt says that they thought they were publishing privately.

Going back to Ruby, you will fail a bunch of CI steps just by leaving defaults in place.

Hey, contributor to rubygems here, there's no source url for ruby gems specification. You can read more here: https://guides.rubygems.org/specification-reference/

You're likely thinking of bundler's source, but even then that doesn't apply to publishing a gem.

> Benefit of the doubt says that they thought they were publishing privately.

In what world is pushing your source code to a venture backed (therefore viral growth oriented) company who promote themselves with "npm Inc supports the JavaScript community by providing the registry where developers publish and share packaged open-source modules" possibly consistent with a view that "they thought they were publishing privately"???

Sorry, but I just don't buy that.

Somebody at the bank fucked up. It cannot possibly be npm Inc's responsibility to detect and somehow police that.

How much of them sending takedown notices was a desperate posturing of "omg please please please please don't use our code!!!"

I can't possibly see how they would possibly have any case.

If their code is proprietary, no one can use it. Even if they accidentally uploaded it to a public site.

I know that, but is the issue that companies are using the code or that NPM, Cloudflare, and Amazon are hosting the repo?

> If their code is proprietary, no one can use it. Even if they accidentally uploaded it to a public site.

Surely this depends on the terms under which they uploaded it. I would expect npm to have a legal structure in place under which code you upload for public use is also licensed for public use.

> I would expect npm to have a legal structure in place under which code you upload for public use is also licensed for public use.

Not how it works. For example, see the license field here:


That would be the "terms under which they uploaded it"

NPM doesn't appear to have a "default license" though, so that would be "no license", therefore normal copyright law would seem to apply, and you can't make a copy of it, and more than you can copy a picture on a billboard or a blog post or whatever.

IANAL but if someone makes code publicly available (for 3 years). Then isn't there an argument to be made that its reasonable to make use of it? Probably not redistribute it, but use it at least. So I'm not even sure an explicit upload license would be required.

You seem to be arguing for an implied license; such things do exist—but the exact scope is often not obvious even to lawyers in the absence of case law covering very similar situations as to the kind of content and the use to be made of it.

My understanding is that it was based on custom/ industry norms. But yes a lot of lawyering would probably be involved.

If you leave your keys in your car for 3 years it's still illegal for me to take a joy ride in it. I don't personally believe in/support the concept of IP but in a world that does (like the US) it doesn't make sense to me that people being able to see your property for 3 years gives them the right to use it.

If you leave you car keys at my house for 3 years does the change the answer? With the car parked on my drive?

I'm not sure a car is the best comparison though.

How about a restaurant putting mint imperials by the cash register. Is it legal for patrons to take one?

Property rights don’t go away because someone made it easy for you to violate them.

Mints are put out explicitly for you to take. Property right intentionally transferred.

Actually, in the US "Abandoned Vehicle" is a legal thing and depending on local laws you might very well be able to claim, and get title to a vehicle that has been abandoned on your property. And the abandonment period can be really short, 48 hrs in some states. It depends on your state's definition of "abandoned vehicle", and local laws, and it will probably require a few trips to the DMV and might require filing in small claims court, but there is a legal process for gaining ownership of a vehicle that has been left on your property.

Same for any lost property, if you find something valuable (wallet full of cash), you generally have to turn it in to the police, and there is a notification process to try to find the owner, and after a period of time (generally 3 months), if no one has claimed it, it's yours. Again, local laws are going to differ, but the general legal concept, that "A finder of property acquires no rights in mislaid property, is entitled to possession of lost property against everyone except the true owner, and is entitled to keep abandoned property."[1] is common.

There's some old saying about possession being 9/10ths of the law....

[1] https://en.wikipedia.org/wiki/Lost,_mislaid,_and_abandoned_p...

It's older than that, it's a Roman legal principle, usucapio: https://en.wikipedia.org/wiki/Usucapio

Your missing the point. How is the transfer communicated? Common law traditions and statutes.

I have never ever seen a sign next to the mints saying they a free for patrons. I just assume because that's the done thing, I would make the same presumption about the software package.

Of someone leaves a car on my drive I can do something about it, you may not be able to do in your territory. I'm surprised there isn't the a legal concept of abandonment though, what do you do if someone drops an empty can on your land?

With physical property, there is the concept of Squatter's Rights. With copyright, if you fail to protect it adequately (which I don't think is very well defined by the court system), then the IP in question can pass into the public domain.

I'm not sure what all rights (physical or otherwise) might be applicable here.

> With copyright, if you fail to protect it adequately (which I don't think is very well defined by the court system), then the IP in question can pass into the public domain.

This is not true. Not even remotely true. It is routine that a company notices someone using their copyrights after decades and then sues about it. Oracle is suing Google over code that was "unprotected" for a decade before they decided to sue. In Australia (I know, different country, but this is the same), Men at Work were successfully sued 29 years after they released "Land Downunder" because it has a two bar riff with similarity to a song written in 1928 [1].

As a side note, I see this all the time. What is it about this particular topic that people seem to (a) consistently confuse these things but more importantly (b) feel confident enough about ti to repeat the confused viewpoint with certainty to others?

You are probably thinking of trademarks.

[1] https://en.wikipedia.org/wiki/Down_Under_(song)

Are you maybe thinking of trademark? If you fail to protect a trademark then you can lose it.

AFAIK, you can selectively (or not at all) enforce copyright all you want and then change your mind later.

Dragonwriters answer was what I was thinking.

Are you thinking trademark rather that copyright? I'm not sure you can fail to adequately protect a copyright in that sense.

You can't, as seen in the case of orphan works, which are often lost because the author is unknown, so nobody can use them.

Has it been tested in court? :)

Yes, of course.

What if the public site states in their terms that they must be granted those rights on the uploaded material, and the actual copyright holder is the one who does the uploading (but accidentally)?

Absolutely not true. Anyone that lives in a country whose legal system does not respect their copyright can use it.

Basically every country has signed a treaty saying their legal system does respect them: https://en.wikipedia.org/wiki/List_of_parties_to_internation...

If you're saying any country where they don't respect it in practice, then sure.

And if it's protected as a "trade secret" and not a copyright (or patent) then you probably can use it without question.

Software is copyrighted "by default". You don't need to apply for copyright like you would need to do with a patent.


USPTO explanation of difference between a Patent, Copyright, and Trade Secret.

The software could contain a trade secret, and someone could discover it from reading the source (e.g. the banks magic evaluation function for credit ratings, or their trading strategy, or ...). That doesn't grant them any protected right on the software, which is protected by copyright.

I’m not sure how universally true that is.

When governments fail to redact documents, it’s on them.

If you “accidentally” talk to a reporter about your solicitor-privileged comms, it’s not privileged anymore.

This isn't an open question.

If you don't have a license from the copyright holder, you can't legally use it, except for fair use exemptions: perhaps you could write a blog post criticizing it.

Was there a licence attached to the files? What if there wasn’t

> If you don't have a license from the copyright holder, you can't legally use it, except for fair use exemptions: perhaps you could write a blog post criticizing it.

To be clear, do the files contains a copyright or licence, if they do not and many companies don’t attach a copyright header to their files. Why would the assumption be that the files are not public domain or free for use

Because unless otherwise stated, they just aren't.

Copyright law in the US grants a copyright to all works without an application (so not the same as a patent)

Theres nuance though, that copypasting a previous comment doesn't answer.

What about public domain works for example? Or you had a good faith belief you had permission from the copyright holder, eg someone misrepresented themselves as the copyright holder, or the copyright holder published the code in public without a copyright notice?

Public domain: any software made to run on current machines is too new to have expired copyright; the author(s) may have dedicated it to the PD, but you have to find that dedication, which is equivalent to a license.

Good faith: that may affect the amount of damages the copyright holder can extract, but it's still illegal to use the software.

Copyright notices: haven't been required for 30 years.

Copyright older than 30 years still requires the notice (and this is banking software).

My underlying point though was that it was an unreasonable answer, to just copy paste the previous answer. No one here that I've seen has claimed to be a lawyer, and no one I've seen has defined what nations laws we are talking about. At that level of discourse, the question posed, deserved a reasonable answer.

> Copyright older than 30 years still requires the notice

Nope, only on works published over 30 years ago. This package was published only three years ago, regardless of when it was created.

There really isn't much nuance under the copyright rules almost universally agreed under treaties like Berne, UCC and TRIPS. This kind of what-ifing a clear statement just sounds like a bad movie trope.

We don't know when it was first published though. If its Cobol code, with dates from the 70s in the comments, that's different to if being JavaScript or some such.

And if you get enough money and lawyers in one place you can create plenty of nuance.

Dragonwriter reminded me of the term, implied licence in another subthread. That clearly seems arguable in this case even if it isn't considered winnable. Case law progresses through winning 'unwinnable' cases.

I think we're approaching this from completely different positions though. I appreciate the what-ifing, exploring the hypotheticals. It isn't as if we have any power to make a difference in a court of law, and I would hope no one is relying on this thread for legal advice.

I have good faith belief that all software on torrent trackers are in public domain or had permission from the copyright holder.

As you see, it doesn't change anything: I will be downvoted, then sued, then jailed despite my beliefs.

That isn't demonstrating a good faith belief.

Buying a Rolex from some guy in a car park is different to buying one from a jewelers. The former wouldn't protect you in any way, the later would let you demonstrate a good faith belief that it wasn't stolen, and wasn't fake.

This is a tangent but there's nothing wrong with buying a fake. So you can have a good faith belief that it was a counterfeit, which can protect you somewhat in the case that it was stolen.

In the copyright example you're probably right.

More generally, say if wanted consumer protections consistent with it being a Rolex, or if you wanted to sell it as a Rolex. Then whether you bought it as a fake does matter.

We're talking about code. Which is more like a recipe than a novel.

If Coca Cola writes down its proprietary recipe on their entrance "by mistake", I can definitely make use of it. Maybe I can't photocopy it for sale, but I can definitely re-use their previously-secret techniques.

I can even say I got it from them through their own error and have the exact same outputs for the exact same inputs.

Trade secrets aren't your secret anymore once you publish them.

All we know in this case is that copyright law was used as a tool to remove it.

> Which is more like a recipe than a novel.

Courts strongly disagree with you.

Do they?

If you reverse engineer a system and write a spec using clean-room technique, it's going to be massively easier for the team to do it if they have lawful access to the no-longer proprietary source code.

And wouldn't that be the method to re-create your own copyrightable implementation of GPL code too?

Thats only true for the US and the countries adhering to US copyright. It's not universally true

It's not "US copyright", it's several international copyright treaties, which 90% of all nations have agreed to: https://en.m.wikipedia.org/wiki/Berne_Convention

The few exceptions are where copyright essentially doesn't exist at all. Where it does, this is how it works.

As someone above posted the wider "List of parties to international copyright agreements", this is one of the boxes that need to be ticked prior to signing any form of deal between countries. It's a kind of 'fundamental' in order to start doing business with that country (or for the country to be taken seriously).

DPRK only recognises foreign copyrights, and have no concept of IP for its own works (because everything is done to superior order, there is no creativity allowed). Micronesia does not have copyright, but has even stricter regime of creative works, amounting to a patent-like protection.

Streisand effect.

Can't you recycle some old lawyer letters then?

Or a little more radical, why even bother with the lawyers? You can explain to them how it is, and if they won't listen, they can sue you. Then you spend some lawyer costs, they lose because the whole thing is ridiculous, and you get a 'cost conviction' or 'cost order' as we call it (kostenveroordeling, where you pay the winning party's costs to prevent abuse of the system) so they pay your lawyer.

So true. How many takedown requests per week do you think Apache.org gets from megacorps of the form "Our employee asked for help, and their debugging logs published our internal URLs. please delete this post and all replies" ?

Still made my day ;-)

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.

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.

Maybe that's the difference between a specialist and a generalist. A lawyer who has experience and expertise working with the software industry is unlikely to make those kinds of silly mistakes. A lawyer who has no software industry experience, who just does general business law, contracts, real estate, wills, etc, who maybe even has some industry-specific experience in other industries like finance or manufacturing or construction, and thinks "software can't be that different"–that is the kind of lawyer who is far more likely to demonstrate that species of ignorance.

I couldn't agree more. I've yet to attend a meeting between legal and tech ops that hasn't been traumatizing for just about everyone involved.

I think lawyers need to talk amongst themselves more; there are certainly even ones who specialise in open-source.

He was also concerned that we were letting people 'View Source' our web pages and stealing our IP.

...and here is where the DRM advocacy comes in. Don't let them ruin the Internet...

You're very lucky if that's all they did. Lawyers sometimes engage into legal pissing contests that can drag on for months on end. There's nothing more infuriating as a sales than two attorneys dragging their feet over legal minutia while literally everyone else (you and your team, your future customer and their team) would like to move forward and get started.

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

Just sayin.

I think that’s the perfect opportunity to let people in the enterprise world you have a solution for their problem. I wouldn’t expect any software targetted so specifically at enterprise to be free, and reaching the IT department of big companies to sell them your solution is a real pita.

So, good job.

They're a little SMH'd over this. And they have to pay their lawyer to deal with it. This cost them money so it is completely appropriate to mention Enterprise.

Naw, the bank probably thought “wow, it’s a good thing we have lawyers on standby for dealing with this kind of thing”.

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

OSS developers should just work for free, and live in destitution. Obviously. ;)

Everyone should live in destitution. Then they'll be free, just like their OSS.

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 ;)

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.

I'm not sure we need another incentive for large companies to not use best-practices and modern technology.

People have enough native productivity that they are able to feed, clothe and house themselves, generate their power and treat most of their ailments with no outside inputs required. In the resulting utopia people write free software in their free time because it is fun.


Please don't break the site guidelines by name-calling, posting unsubstantively, or slurring $people.


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

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).

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.

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".

>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).

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.

An air gap will stop innocent mistakes and outsiders.

And kill dev productivity.

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.

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

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

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

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"

My bad, didn't see that one!

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.

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.

As someone who also works at a bank (though not a large national one) I get the same feeling, though I understand it to an extent. Not complying to bank standards means you get dinged if you get audited. Getting dinged means you will most likely get your budget cut by an amount next quarter. Or get the group "reorganized".

"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".

Option C: Easy "billable hours"

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.

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

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

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

https://docs.npmjs.com/files/package.json#private anyone hoping to avoid the same fate

Anyone know what bank? Or what package?

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

npm install goldmansachs

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

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.

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?

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.

Hide the embarrassingly ugly, also.

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

npm doesn't allow you to delete a package once it has some downloads to prevent another left pad incident. I'm sure they can make exceptions, but it's not as simple as a quick CLI command.

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

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

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

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

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.

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

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.

Probably an internal application. All internal systems are moving to the web.

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...

You can't install from npm?

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.

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.

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.

Nope. Only from the internal mirrors.

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

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.

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

I hope he send them the bill for his lawyer.

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

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

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.

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

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.

No one would use such a thing. Very few open source code is in the public domain. The only one I can think of off the top of my head is SQLite.

In fairness, the bank in question might use such a thing, because they have difficulty making decisions that abide by their own policies.

There is a `private` setting in the package.json to avoid this situation.

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

Which bank?

it's probably just a data visualizer component.

Abused the DMCA also.


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.

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

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

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.

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.

That is absolutely not true, and it flies in the face of the notion of "due diligence".

This bank uploaded their own code to the repo, and when they found it they didn't bother to do any investigating before they started sending legal demands.

It was 100% their responsibility to ensure that they were not responsible for their own leak before they started making legal threats.

They decided to skip due diligence, and they should pay the price for wasting others' time and energy, regardless of their "intentions".

The upload itself does not constitute the Company's policy. It is not "The Bank's" action. There is a legal standard for a company's action, which is a signature by an executive or possibly a lower signing officer. The employee that uploaded this almost certainly is not an officer. Their failure to discover that the upload was their own error is their failure.

Thus, a DMCA request is appropriate, as the GP points out, the original employee that did the action quite likely cannot undo that action.

IIRC that's not quite how it works. It can be complex but one element often involved is whether the third-party had an objectively reasonable belief that the employee had the requisite authority. Who else than a software engineer would be uploading to a code repository?

That said, that relates mostly to vanilla contract and agency law. Copyright law can add its own twists.

The banks employee granted NPM a (probably) valid license to distribute the code (quoted below - from the tos). Submitting a DMCA request claiming requires claiming under penalty of perjury that no such license exists. That's (probably) incorrect, any lawyer reasonably knows that a license would have been granted, and as such (probably) criminal. Unfortunately (?) this sort of perjury is never prosecuted in practice.

> (From npm tos) Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services

They can't make the argument that the bank employee had no legal right to grant NPM a license as the bank owns the copyright and not the employee?

Unlikely, npm has a reasonable belief that a bank employee entering into a contract with them has the right to do so, and that is generally sufficient for the contract to be binding on the bank.

Yeah they can. This whole thing sounds ridiculous. I have a hard time imagining this ending any other way than the code being removed if the bank presses the issue.

How is it not? The bank uploaded it by mistake. Now some other entity has to pay because of that. There're other ways of handling this.

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.

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?

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/

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

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

There are many ways to specify dependency except from central npm server: https://docs.npmjs.com/files/package.json#dependencies

That includes tarballs on http, git repos and even freaking local directories.

For companies where putting packages on smb mount is treated as non-enterprisey, npm have "npm enterprise" offering: https://www.npmjs.com/products/enterprise

Whats wrong w/ nexus? https://blog.sonatype.com/using-nexus-3-as-your-repository-p... All our devs have our group repo configured as default. Any publishing is done to our private repo (via CI only) and any public package is pulled through the proxy repo, this way all packages are cached in our private repo so when npm registry goes down / someone unpublishes (which happens/ed?) our CI server doesn't die.

Nexus is great, comes with an easy to use docker image - and also works as a Nuget repository and more.

Just put the package in a git repo like Github and point to it w/ package.json

EDIT - I see what you are saying - your own registry with browser and all.

Its not official, and not free, but GitLab can host NPM packages: https://about.gitlab.com/2019/01/22/gitlab-11-7-released/#np...

There's LOTS of solutions for your own NPM, not to mention you can use git over ssh or http(s)... there are proxies, self-publish software. Some of it open-source, other options not so much. IIRC, you can even run your own npm if you wanted to.

Gotta pay the bills somehow. I think that providing enterprise support is a very good way to do so. There is nothing compelling them to develop an official solution and a third-party one already exists. It looks like this is a good example of open source WAI.

JFrog has an open-core/OSS repo for NPM, I believe.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact