5 ms·

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 `pri

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 8y ago
> 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 8y ago
  Then I am not sure what did prevent publishing, but it was not published.
  - deleted 8y ago
    [deleted]
  - joshuacc 8y ago
    npm orgs are free, but the org has to be created before you can publish to an org's scope.
nukeop 8y ago
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.
- Ndymium 8y ago
  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.
arcatek 8y ago
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 :)
mfoy_ 8y ago
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.
ndonnellan 8y ago
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.
sh4dow 8y ago
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...
- mstade 8y ago
  > 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!)

rounce 8y ago

> 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 8y ago
Then I am not sure what did prevent publishing, but it was not published.
- deleted 8y ago
  [deleted]
- joshuacc 8y ago
  npm orgs are free, but the org has to be created before you can publish to an org's scope.

nukeop 8y ago

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.

Ndymium 8y ago
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.

arcatek 8y ago

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

mfoy_ 8y ago

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.

ndonnellan 8y ago

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.

sh4dow 8y ago

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

mstade 8y ago
> 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!)