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 :)
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...
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.
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.
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.
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.
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.
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.
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.
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".
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".
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.
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.
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.
[+] [-] Ndymium|7 years ago|reply
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.)
[+] [-] ndonnellan|7 years ago|reply
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.
[+] [-] arcatek|7 years ago|reply
[+] [-] rounce|7 years ago|reply
(Public) Orgs _are_ free on NPM (at least nowdays) so maybe even that wouldn't have saved you.
[+] [-] mfoy_|7 years ago|reply
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.
[+] [-] sh4dow|7 years ago|reply
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...
[+] [-] nukeop|7 years ago|reply
[+] [-] seldo|7 years ago|reply
[+] [-] omouse|7 years ago|reply
Or something to that effect. Or maybe companies can just pony up for NPM Enterprise which fits their use case.
[+] [-] seniorsassycat|7 years ago|reply
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.
[+] [-] tombert|7 years ago|reply
I can't possibly see how they would possibly have any case.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] ahallock|7 years ago|reply
[+] [-] linsomniac|7 years ago|reply
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.
[+] [-] skissane|7 years ago|reply
[+] [-] elliekelly|7 years ago|reply
[+] [-] userbinator|7 years ago|reply
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...
[+] [-] ddebernardy|7 years ago|reply
[+] [-] ronilan|7 years ago|reply
Just sayin.
[+] [-] bsaul|7 years ago|reply
So, good job.
[+] [-] JustSomeNobody|7 years ago|reply
[+] [-] orblivion|7 years ago|reply
[+] [-] fiatjaf|7 years ago|reply
[deleted]
[+] [-] gauravphoenix|7 years ago|reply
[1] https://redlock.io/blog/docker-repo-public-access
[+] [-] aboutruby|7 years ago|reply
[+] [-] koolba|7 years ago|reply
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|7 years ago|reply
[+] [-] born2discover|7 years ago|reply
[+] [-] beager|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] redshat|7 years ago|reply
[+] [-] mstade|7 years ago|reply
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.
[+] [-] huffstler|7 years ago|reply
[+] [-] vortico|7 years ago|reply
"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".
[+] [-] mnutt|7 years ago|reply
[+] [-] koolba|7 years ago|reply
What stops someone from creating that account and owning that org?
[+] [-] tuxracer|7 years ago|reply
[+] [-] mstade|7 years ago|reply
[+] [-] FlowNote|7 years ago|reply
npm install goldmansachs
[+] [-] jhare|7 years ago|reply
[+] [-] koolba|7 years ago|reply
Maybe $35/byte. Then the lawyers could haggle, get it reduced to $35/non-white space byte, and feel like they accomplished something.
[+] [-] alkonaut|7 years ago|reply
If someone finds a module of BankX's boring backend code, what is the risk/problem for the bank?
[+] [-] uberswe|7 years ago|reply
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.
[+] [-] z3t4|7 years ago|reply
[+] [-] Klathmon|7 years ago|reply
[+] [-] ahallock|7 years ago|reply
[+] [-] wolco|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] AlexTWithBeard|7 years ago|reply
I was upset about it when it was introduced, but now I start to see the point...
[+] [-] linsomniac|7 years ago|reply