6 ms·

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 dia

• vvoyer 8y ago
  No alert box ever will save you from doing the biggest mistakes, most people don’t read them.
  • ivan_gammel 8y ago
    Just compare this to publication to Maven Central - you’ll never publish there by accident exactly because there are significant barriers. Public NPM repo should not be that easily accessible for upload.
    • kbenson 8y ago
      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.
      • ljm 8y ago
        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.
        • kall 8y ago
          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.
        • gowld 8y ago
          The JavaScript community is moving into the Enterprise and is discovering Java's good ideas from 1995
          • bigiain 8y ago
            Excellent. 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...
        • jeswin 8y ago
          > 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 https://docs.npmjs.com/about-scopes
  • deleted 8y ago
    [deleted]
• OnlyOneCannolo 8y ago
  What you're describing is consumer protection, but a company isn't a consumer. The bank responsible for their own actions.
• deleted 8y ago
  [deleted]
• ljm 8y ago
  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.
• knicholes 8y ago
  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.
• satori99 8y ago
  Setting `private: true` to your package.json will prevent this from happening
  • duncan-donuts 8y ago
    setting `public:true` would solve this problem
    • isostatic 8y ago
      But default should be public - it's an open source piece of software
• newsbinator 8y ago
  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".
• austincheney 8y ago
  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.
  • xemdetia 8y ago
    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.
    • austincheney 8y ago
      > 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.
• philliphaydon 8y ago
  It should not auto create accounts. Compared to Nuget. I find NPM absolutely scary to use because it’s unpredictable. (Personal opinion)