Live data from Hacker News

Major bank accidentally published a private package to the public NPM Registry

twitter.com

191–200 of 236 posts

Re: Major bank accidentally published a private package to the public NPM Registry

#191
post #46

Earlier quoted context omitted.

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.

Re: Major bank accidentally published a private package to the public NPM Registry

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

Re: Major bank accidentally published a private package to the public NPM Registry

#193

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 repos…

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

Re: Major bank accidentally published a private package to the public NPM Registry

#194
post #103
post #98

Earlier quoted context omitted.

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…

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…

> 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

Re: Major bank accidentally published a private package to the public NPM Registry

#195
post #193

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 repos…

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

Re: Major bank accidentally published a private package to the public NPM Registry

#197

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.

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.

Re: Major bank accidentally published a private package to the public NPM Registry

#198

Earlier quoted context omitted.

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

Re: Major bank accidentally published a private package to the public NPM Registry

#199

Earlier quoted context omitted.

> 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: https://www.npmjs.com/package/unlicensed

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.

Re: Major bank accidentally published a private package to the public NPM Registry

#200

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 repos…

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.
Post reply on HN