[meta issue] unpublish policy

[ashleygwilliams]

today we published a blog post on our first steps towards a new unpublish policy. this issue is a place for readers to comment an ask questions about the unpublish policy. comments and questions that are not specific to the unpublish policy will be moderated.

link to the blog post: http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy

remember: npm has a Code of Conduct

[groundwater]

In the event a package has an open-source license like MIT that allows redistribution, I think maintaining a package in the registry makes sense.

There are however packages listed with non-open licenses, and likely in some cases licenses that can be revoked. In that case you effectively have unusable software published to the registry. I recognize one solution might be "only open licenses allowed" but that's probably not reality.

I suppose one could deprecate the module, but I think most people ignore warnings during install.

[searls]

First, I think this is a terrific policy change in favor of dependency stability, so kudos! I'm all for dependency registries treating their artifacts as permanently etched in stone for the sake of keeping end-users' software working. It's in that spirit that I'm asking this question:

The policy change affects how npm users who own depended-on packages can un-publish their own content from the registry, but I'm curious if it affects how npm will respond to DMCA takedown notices of depended-on modules. If npm voluntarily acquiesces to a takedown complaint (to retain its DMCA safe harbor protection), it might find itself putting npm install users in a very similar situation. Obviously, there's only so much that could be done if npm were ultimately compelled to take down a module by court order, but other types of content hosting services have shown there is a pretty broad range of potential responses to DMCA takedown requests.

Ideally, I'd like to see npm take a stance that defaulted to defending end-users of packages, potentially providing tools for addressing infringement with a less-blunt instrument than removing a module (or a version of a module) altogether.

I realize this is a hypothetical, but the situation that brought this policy change about is only one logical leap away; if npm had been dealt with a DMCA takedown or a cease & desist for the leftpad module as opposed to kik, it would have been put in a similar situation, even without the rogue package maintainer that this policy seeks to mitigate the impact of.

[mattdesl]

Nice post!

Question about this:

if removing that version of your package would break any other installs

1. How can you detect this reliably? What about private modules, unpublished GitHub repos, devDependents, etc?
2. Does this extend to all versions of a module? foo@1.2.2 might not have any dependents, but foo@1.2.1 may have a single dependent. Because of semver, pinning, magic zero and other complexities, foo@1.2.1 can still cause widespread breakages across the ecosystem.

The second point already happened when esprima-six was unpublished – it's latest version had zero direct dependents but its removal still caused widespread issues for many npm users.

[isaacs]

@mattdesl For dependencies, we can query for all the dependents of a package, and then check what their dependency is. If it's pinned to a specific version, then we'll see that. Removing version 1.2.1 will still fail if 1.2.1 is more than 24 hours old, and then support will be able to deny the request if we see that case.

For the very rare cases where a package has zero dependents, on any version, we can still look at downloads. It's a hard thing to judge programmatically, because of the statistical noise introduced by bots and downstream replicas that download every package. But it's not completely impossible to determine if something is hugely popular (hundreds or thousands of downloads) vs more or less unknown (7 downloads in the last month).

In any event, we'll be erring hard on the side of "No, do not unpublish, use deprecation or transfer ownership" in any case that is even slightly questionable.

[tlrobinson]

(cross-posted at https://news.ycombinator.com/item?id=11383113)

Because all dependents are satisfied by 1.0.1, support agrees to grant Supreet’s request to delete 1.0.0.

There are some good changes here, unfortunately this policy will still break projects that use npm shrinkwrap to lock down specific versions, which IMHO, anyone who wishes to retain their sanity will do.

When this happens AFAIK there's no foolproof way to "patch" your npm-shrinkwrap.json with the new version without deleting it and re-running shrinkwrap, and thus possibly bumping versions of every other package as well. The usual recommendation seems to be "find and replace" the version in npm-shrinkwrap.json with a regex, which is fine if the package's dependencies didn't change but will break if a dependency is added.

I'd love to know if there's a better way.

FWIW, if you think this is a very rare occurrence, it's now happened to me 3 times in last few months, the latest being less than a week after the left-pad incident.

[GlenTiki]

I'm wondering about private modules, can you straight up unpublish them or must you go through support for it, as with public modules? You would more than likely own or collaborate on the private modules that depend upon it, so you'll only break your own things, which at the end of the day, is your problem, not npm's.

[isaacs]

@groundwater

There are however packages listed with non-open licenses, and likely in some cases licenses that can be revoked. In that case you effectively have unusable software published to the registry. I recognize one solution might be "only open licenses allowed" but that's probably not reality.

By publishing it on the npm registry, you agree to let us distribute it. Of course, users might not have any rights to use the package, but it's out there, and up to real lawyers to fight that one out. Ultimately, it's not our responsibility to enforce your license. You publish it, it's published.

@searls One rare scenario where we are legally required to take down a module is DMCA. If the proper forms are followed, we have to follow procedure. Our policy is here: http://npm.im/policies/dmca

[ashleygwilliams]

to reiterate what @isaacs, @groundwater by publishing your package to the npm registry you agree to npm's terms which involve a special license that allows us to distribute it, regardless of whatever license you have (or have not) assigned it. you can read more about that here: https://github.com/npm/policies/blob/master/open-source-terms.md

the latest PR to that policy is from our lawyer specifically trying to make this as clear as possibe: https://github.com/npm/policies/commit/140ed66e2169e248674fe16e920ba9a052c8a337

[isaacs]

@tlrobinson There are two things here: the first is "how to more easily update shrinkwrap", and the second is "how to prevent pinned versions from breaking users".

For the first, the latest and greatest npm@3 supports updating your shrinkwrap when you npm install foo@latest --save. That's a smaller problem. (Or a regex replace, or text editor, or delete and re-run shrinkwrap, etc.)

For the second, I think the same logic in https://github.com/npm/policies/issues/44#issuecomment-203013591 would apply. We'll look at that case, and probably be able to get it right most of the time. When in doubt, we're going to err on the side of not allowing deletions.

I don't think this (or any!) policy is going to be 100% airtight in every conceivable scenario. But the perfect is the enemy of the good in situations like these. We're closing a lot of problematic issues with this change, but we aren't under the illusion that this sort of work is ever completely "done".

[mattdesl]

Another thing that might be good to clarify is how the unpublish command or policy is handled by contributors to a module, rather than the original authors. Azer was able to unpublish some modules that he was just a contributor to, rather than the original creator.

@isaacs Thanks. I'm not sure download counts will tell you much. Some of our private (client) work may sit idle for months before we need to "revive" the project by cloning and re-installing dependencies.

[shazron]

Because all dependents are satisfied by 1.0.1, support agrees to grant Supreet’s request to delete 1.0.0.

Getting "all" dependents to agree would be problematic, this is the Internet (plus lag in responses). Perhaps more of a consensus or majority instead (especially if you need to remove a vulnerability). I assume that will be at the discretion of support anyway and not a hard and fast rule.

[tlrobinson]

@isaacs I don't think npm@3's install --save support for updating npm-shrinkwrap.json will help with updating sub-dependencies that I don't depend on directly. I suppose I could do npm install foo@latest --save then delete "foo" from my package.json. As long as the version I wanted to update was in the top level node_modules that would work, but if there were more than one version and the broken one was in a nested node_modules directory this wouldn't help, would it?

Separately, this is probably a lot more work for you guys, but how about just putting unpublished packages in a pseudo-unpublished state where they don't show up in npm show etc and warn users installing them, either permanently or (more likely) for a grace period. Something like left-pad@0.0.2 has been deprecated and will be removed on 2016-04-15. It's possible this is due to a security vulnerability, please investigate and remove or upgrade this dependency before that date. I'm sure this copy could be worded more elegantly, but it has the benefit of not breaking people's builds and warning them of a possible security issue.

In the case of https://github.com/chalk/ansi-styles/issues/15 version 2.2.0 was unpublished because it was "broken" from the developers' perspective, but from my perspective it was working just fine (they admit chalk's use of ansi-styles was not broken), and the act of unpublishing actually broke things for me. According to your new policy as long as they published 2.2.1 before asking to unpublish 2.2.0 the request would still have been granted?

[ashleygwilliams]

@shazron

I assume that will be at the discretion of support anyway and not a hard and fast rule.

exactly that. hard and fast rules are also often easy to exploit, for now we are relying on the discretion of humans as we see how this current policy plays out. i imagine some patterns will emerge that will help us further this policy.

[ashleygwilliams]

@mattdesl it turns out that "ownership" is a significantly complicated idea in the npm public registry, though it may seem simple at face-value. we know that we need to make "ownership" clearer, and to do so we'll need to make some technical decisions and changes. top of mind, for sure.

[jamietre]

One thing that is not addressed by this policy change is the potential for a legitimate npm package owner's credentials to be compromised, allowing an attacker to publish a new version of a trusted package containing malicious code.

Because npm automatically installs the most recent version of a package, for packages with many consumers, this would result in a very rapid spread of a virus or trojan horse in a short period of time. That is, if I get access to publishing credentials for foo, and publish foo@1.4.5, any consumers depending on semver ^1.4.4 (or indeed any prior version in the 1.x range) will automatically consume it with npm install.. Since this is a very common pattern - npm install foo --save will automatically create a dependency using this type of semver - the vast majority of consumers simply doing a clean install of something would probably consume 1.4.5 automatically.

This risk could be greatly mitigated by changing the semver matching policy to consume the oldest matching version instead of the newest matching version. This would mean new versions of packages are never consumed automatically, except as explicitly required by a consumer. This would greatly slow the speed with which a new version of a package would be consumed.

This is a saner policy for software developers for other reasons, anyway. We make a habit of using shrinkwrap all the time for production code, since even with semver, people make mistakes, and a new version could introduce a problem you didn't have with the current version you were using. We don't want to consume new versions of anything automatically, unless we have to or need to for some known reason. Generally, I would think most people would only want to consume a new version of a package to solve a problem, or make use of a new feature. Either of these reasons would result in a deliberate decison to upgrade, rather than essentially having new versions of code continually pushed.

Have you given consideration to changing this behavior for npm install?

[ashleygwilliams]

hi @jamietre - a couple of things:

One thing that is not addressed by this policy change is the potential for a legitimate npm package owner's credentials to be compromised, allowing an attacker to publish a new version of a trusted package containing malicious code.

this policy was never meant to address that problem.

This risk could be greatly mitigated by changing the semver matching policy to consume the oldest matching version instead of the newest matching version.

this is the opposite of npm's stance on semver. automatically including patch versions with bugfixes is exactly what we want to happen. if you, personally, don't want that, you are free to use other semver expressions or specify a single specific version.

also: semver is not something invented at npm and we do not plan on changing it. for more info, see http://semver.org/

[evanlucas]

Are private packages hosted by npm considered to be dependents when a request to be removed comes in?

[jamietre]

@ashleygwilliams I understand and believe in semver. But semver describes a way to describe and match compatible versions. The policy on which version you install given a particular semver range is a decision of npm's, not a mandate of semver.

I am simply pointing out a risk as a result of the policy of automatically installing the latest version matching the semver and proposing an alternative. This is consistent with the default behavior of other package managers that I've used (Maven and Nuget). I understand what the current stance is, the point of this comment is to ask that it be reconsidered, just as you reconsidered the policy on unpublishing.

I realize this policy isn't meant to address this problem - but in the context of everything that happened it seems a reasonable time to discuss the security issues that the events of last week brought to light.

[ashleygwilliams]

@jamietre at this moment, we aren't. i'd be interested in reading Maven's and/or Nuget's rationale if you happen to have any links at hand, though.

[isaacs]

@jamietre If the reason for a later-than-24-hours unpublish is "this thing has a security vuln", then I'm sure that support will act appropriately. (In fact, in that case, it should be sent to security@npmjs.com and/or abuse@npmjs.com instead!)

@tlrobinson Ah, ok, if it's a nested dep, then updating the shrinkwrap is indeed trickier. Sorry, I didn't catch that on the first pass.

In general, yes, we'll almost always use a deprecation warning for a period of time before deleting the package. It's a good practice anyway.

[jamietre]

@ashleygwilliams Here's a couple refs about nuget:

Release notes for 2.8, where the strategy was first introduced

Blog that refers to it

"NuGet by default loads the lowest possible version it can match. In this case that’s 2.50, even though 2.55 is available. There’s a bit of discussion on why this somewhat unintuitive behavior occurs. Summarized, it amounts to this: lower versions are safer and avoid pulling in newer versions of components that might break existing applications/components that depend on the same component. It avoids pulling in newer versions in unconditionally."

I am actually having a really hard time finding anything specific about Maven. The discussion and documentation is very fragmented. I always hated it anyway and am glad I don't use it anymore so maybe not the best example ;) but I will continue to look around.

@isaacs in the scenario I'm imagining, the damage would be done long before 24 hours had passed! The combination of relatively weak security for npm authentication (username/password) and automatic-latest-version-consuming is a juicy attack vector for a mischief maker.

[mcollina]

@isaacs @ashleygwilliams this is an awesome news. Congrats and well done!

[Krettis]

What about this: Why not use a uuid instead of a namespace in your package depency list? The namespace ( plus semver ) could be something what is public provided by npm. But the uuid's are only known by the packages who use the package.

For example You are using package 'supertool' Supertool has a depency of package 'blacksheep@4.2.2' with the uuid 94653e3f-50ec-47e5-9666-b8e7d0d60bcc in your package list Package 'sunbutshine' also has the same blacksheep@4.2.2 but with the uuid b946abb7-3d50-4ad6-8ade-55d029a8bb7d This way the focus is not on the package blacksheep itself but on what links between two packages. Doesn't matter anymore if the packages namespace is public or not. This package with its version will never be broken, because the link-uuid is what counts and will never be deleted. Even though the package could be unpublished 50 more times, it will never be broken for no one.

Suddenly... Corp. OzzyOzz claims package Blacksheep. Namespaces need to be unpublish. No worries. The links supertool and sunbutshine will always be available.

A new challenger appears If a new package called 'WolfNeedBreakfast' would use the uuid of supertool or sunbutshine npm could easily block cause they aren't the authorized package to use it. They would need to create a new link by referencing to the namespace plus version.

Unpublish within 24 hours You would only unpublish the public namespace+version. So for example 'Blacksheep@1.0.0' would have a lot of problems and goes back to 'Blacksheep@0.6.3'. In between this time it is up to the other folks who upgraded to the first version if they still use this version or not. It needs to be static imo, because it is already out in the open. The next version Blacksheep when they have a fix is according to semver 'blacksheep@1.0.1'. And blacksheep@1.0.0 will never be distributed as a namespace by npm itself.

[eddieajau]

I think the changes are good overall, but here are a few comments/thoughts:

1. I think the policy should only apply to public packages, not private packages (that have always been private).
2. However, a public package that changes to private access should be considered equivalent to unpublishing.
3. I think you may need some flexibility with the 24-hour window as that may not give corporate users enough time to mitigate a problem on the next "business day". I can actually seeing this as a hard sell to my manager and will probably scare them off at best contributing to Open Source, or at worse using npm at all even for private packages. Just something to think about.
4. I think you might need to give an indication of what the SLA for responding to post-24-hour unpublishing requests.
5. Does npm need to consider the use-case where a significant security vulnerability is found in a package and the maintainers are not contactable, requiring npm to intervene in some fashion (which may lead to unpublishing the vulnerable package)?

[ashleygwilliams]

hello @machineghost. this issue is specifically to discuss the unpublish policy. it is not appropriate AND derailing to attempt to discuss name dispute policy here. i have moderated your comment.

[arimathea]

I appreciate that you guys have clarified the policy. However, this line is fairly concerning:

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.

This assumes a lot about the license involved. Consider the case where the author of a piece of code does not necessarily have the legal authority to grant you this license. You might argue they do have the authority and are warranting that by publishing the code to NPM, but I suspect there are a bunch of rightsholders that may beg to differ.

If you contact support, they will check to see if removing that version of your package would break any other installs. If so, we will not remove it. You’ll either have to transfer ownership of the package or reach out to the owners of dependent packages to change their dependency.

This is also really concerning. It places the entire onus on the author of the package to contact authors that may or may not reply in a timely fashion. There is no published time limit for these replies from absentee package authors. Any author of an npm package can block any other package's removal, indefinitely, and that is terrible design.

I don't think it makes sense, in the slightest, for npm as an organization to take on the additional liability to insure some sort of sane dependency model resolution. That really needs to be on the author of the code. The "right answer" here is to fail intelligently in the face of a missing library with a responsible error message and suitable behavior that doesn't try to build something that won't work, not to run roughshod over authors of code, rightsholders, and people who want nothing more to do with your model of "we own everything, kthxbye, and if we don't like the fact that you've unpublished well then go pound sand, we're not going to respect your decision as the author of code".

[ashleygwilliams]

hi @arimathea. we appreciate your feedback and have considered your concerns but are ultimately going with the direction we have published. remember that contacting support re: unpublishing is the safety valve. if bad actors (i.e. dependent packages that specifically refuse to change deps) are encountered, that is something our support humans will notice and take care of.

is there a specific question you have?

[arimathea]

1. What is the expected round trip time of a support human?
2. What percentage of NPM packages is "stale" e.g. not updated frequently? Are you tracking any statistics on the number of package authors whose linked github repositories are unresponsive?
3. Under what circumstances does a currently published package fall under these new rules? Did you send a note to all npm package authors asking them to consent?
4. In the case of a legal challenge by the author(s) or rightsholders of the code in question, do you intend to defend your ability to continue publishing the package?
5. What are the thresholds used? Using humans implies judgment. If the package has one listed dependency, is that an issue? Ten? Twenty?
6. Are all packages treated the same way? What about a package that has never been downloaded?
7. If your support humans get overloaded, at what point do you anticipate migrating to a more scalable system?
8. How long does your sensible support human expect to take resolving a package that desires an unpublish that other packages depend on and are unresponsive? Modulecounts suggests 250k packages currently in NPM. If we assume 1% of those packages might have these issues, that's 2500 total, with an additional 4 (1% of 446 average) a day, for a total of 1,460 over the course of a year. Are these statistics accurate?
9. What do you think the proposed contact mechanism is or should be for a developer who wishes to unpublish their package? "Any means necessary"? If a developer wishes to unpublish a package, do you accept their warranty that they've made all attempts to communicate to the people that depend on their package?
10. If a developer thinks there is someone, or multiple someones, who are infringing their license for a given package, how does NPM propose to deal with that dispute? NPM's terms of service seem to indicate there is no avenue for a developer to stop such a package from being available to the infringer short of a lengthy court battle.
11. Does NPM intend to treat larger companies different than smaller companies when it comes to this policy?

[ashleygwilliams]

those are great questions @arimathea, thanks for asking them. it's gonna take a second for me to get all the answers, and some of them don't exist yet, but know that i see this post and intend to answer it, though it will likely be midday tomorrow, PST.

[arodland]

If you had announced this in advance of implementing it, I bet you would have seen thousands of unpublishes in the time in between (which, I'm sure, is why you didn't), because I'm sure that a substantial fraction of your existing developer population has no wish to have their work distributed through such a system. As it is, I wouldn't be surprised (or displeased) if your support queue got completely snowed under.

[ashleygwilliams]

we are announcing this before we've implemented it @arodland. we are announcing this because we believe developers deserve to know. if they wish to unpublish, they currently can.

we developed this policy by listening to the concerns and asks of our community. we are a platform for the community and care deeply about their interests. this is the outcome of that care. we can't please everyone but we are trying to be receptive. the overwhelming response to this policy has been extremely positive.

we know that we rely on heavily on our support people, we always have. it will be a new challenge and we are excited to see how this goes. we will probably make mistakes, but we will be open and iterate.

[arodland]

@ashleygwilliams I don't see any mention of a timeframe in the blog post, only "going forward" which implies that it's true from the time of the post onwards. It might be helpful to clarify that :)

[ashleygwilliams]

@arodland that's good feedback- thanks!

[arimathea]

if they wish to unpublish, they currently can.

If a developer unpublishes today (or before your policy takes effect) a package that is depended on highly by other packages, you won't intervene? Did I hear that correctly?

[ashleygwilliams]

i didn't say we wouldn't intervene, @arimathea. i imagine our feels/actions would be similar to the incident with left-pad. software takes time to write tho! my point is we have now written this policy and we wanted everyone to know ASAP. we are also implementing it ASAP. there is a gap period. it is what it is. we believe in this policy and will be using it as a guide for our future actions.

[ashleygwilliams]

hello @phillip-haydon @lucentminds @simov. this issue is specifically to discuss the unpublish policy. it is not appropriate AND derailing to attempt to discuss name dispute policy here, or any other topic. i have moderated your comments.

[ashleygwilliams]

@phillip-haydon if you continue to derail this issue and use abusive language i will ban you from the npm Github org. please note our Code of Conduct, linked above. i have moderated your comment.

[dmethvin]

Per threads on Twitter including here we have a suggestion to implement some way to abandon/disown a published module. That circumvents the problem with owning a module you don't want to be associated with but still leaves it published with some "placeholder" new owner.

[dmethvin]

Also I agree with @groundwater's comment above that as long as the license permits it npm should prevent all the dependents from being broken by unpublishing. It might be good to have npm explicitly state that by publishing on npm the owner grants npm this right (if it doesn't already).

[ashleygwilliams]

banned @phillip-haydon. comment was moderated.

[getify]

I have a few ideas to extend the new notions of the "unpublish" policy (some the source of @dmethvin's comment just now):

1. Support an abandon or disown command, which unconditionally removes all association of my user account to a package. Instead, it will now be "unowned" or maybe owned by "npmbot" or something like that.

   package pages of an abandoned package should display a notice/warning. installs of an abandoned package should show a warning.

   other users could apply to adopt an unowned package by contacting npm support, on a first-come-first-served basis with human judgement optionally.

2. An abandon operation could also move the package to an "archived" status, wherein the package continues to be available for install with warning, but no longer has a visible package page and also is removed from search results. A special "archived" section of the site could list these packages.

3. An abandon operation could also unconditionally "unpublish" all versions which weren't actually depended upon, keeping only the versions that are minimally necessary to not break other packages.

   ideally, the npm system would track this over time, and as soon as a package@version becomes no-longer-depended-upon -- I'd expect this will happen as people migrate away from an abandoned package -- then the version in question will be unpublished.

[ELLIOTTCABLE]

@getify basically nailed my thoughts, here.

I'd also like to :+1: this:

This is also really concerning. It places the entire onus on the author of the package to contact authors that may or may not reply in a timely fashion. There is no published time limit for these replies from absentee package authors. Any author of an npm package can block any other package's removal, indefinitely, and that is terrible design.

I'm glad to hear that Npm Humans™ are a layer-of-defense against this … but inherently, economically, Npm Humans™ have a very high cost. I really, really think they shouldn't be the first-and-only layer of defense; that's going to encourage some bad behaviours and designs. /=

[ashleygwilliams]

hey @getify @dmethvin thanks for this thoughtful extension. i'll be talking to the team about it this week. when thinking about this policy we thought more about preserving the package, and you're right that sometimes all someone wants is to remove their association. this is exactly what this issue is for, thanks so much for sharing.

@ELLIOTTCABLE you are right, and as we explicitly stated in the post, humans aren't scalable. the trick here is that we spent a very long time musing on algorithmic restrictions and it turns out that those also encourage bad behavior and designs. the best i can say is we're working on it, but keeping it in the hands of humans makes it a lot easier to protect people from automated bullies which was a major concern for us. we'll also need to update our policies and terms to specify new and strange bad behaviors that we don't accept (squatting as a dep to prevent unpublish, etc). this is a first step! there is more to come, there always is.

[isaacs]

@dmethvin

It might be good to have npm explicitly state that by publishing on npm the owner grants npm this right (if it doesn't already).

It does. See: https://github.com/npm/policies/blob/master/open-source-terms.md#your-content

@getify If I understand your technical suggestion, that sounds like it's all doable today (and in fact, something that npm support folks will nudge would-be unpublishers towards).

IIUC:

npm disown $pkg = 
  npm owner add npm $pkg
  npm deprecate $pkg "This has been abandoned, if you want the name, contact <support@npmjs.com>"
  npm owner rm $(npm whoami) $pkg

This would definitely be a useful pattern for the "I'm done with this, moving on (responsibly)" case.

[simov]

@ashleygwilliams (squatting as a dep to prevent unpublish, etc)

Great! My comment was exactly about that, though I'm pretty sure you know about that fake accounts that crawled the registry yesterday.

I was wondering how a fake module that depends on all other modules by a star * affects the unpublishing. To my understanding that means only the latest version will be unpublishable?

[ashleygwilliams]

@simov we are aware of these accounts and are currently discussing how to handle them internally. our thinking so far is thus: a package that has no other functionality other than to dep on packages to prevent their unpublishing is not acceptable use of npm. such packages will need to be removed. they are not considered valid deps and when someone attempts to unpublish a package and that package is only depended on by these automated troll packages, we will remove the troll packages and then allow the unpublish.

[ashleygwilliams]

also sorry, i think i misunderstood the intention of your previous comment, which is why i moderated it. for others on the thread, this was @simov's original comment:

[machineghost]

@ashleygwilliams I apologize for posting in (what I thought was the correct, but evidently was the wrong) issue. Could you please direct me, and any other interested parties, to the appropriate issue to discuss NPM's name giveaway policy?

[GlenTiki]

@isaacs I believe the archiving option might be the best choice. If I might add to this suggestion however: When it is archived, people could fork it and publish on their fork. The warning for downloading an archived version would include links to all forks for devs to check out & update there dependencies.

This would require devs to acknowledge that there is a new maintainer for a package they are using, and get them to check out if that maintainer is doing nefarious things. It would also allow NPM to automate the process more.

How would you track forks however? A forked-from field in the package.json? Track forks from the original github repo? (not always possible as the repo might not be github based, etc)

Additionally, I think forking on NPM might be a nice feature.

[ashleygwilliams]

no problem, @machineghost, mistakes happen. since we have not yet announced updates to our name-dispute policy, we aren't hosting a public forum to discuss it yet. we're a really small team and i can really only moderate and respond to one policy change at a time.

we know that the community is still super upset about how the name situation happened last week. we also have a lot of feels. we aren't ignoring it, just taking one step at a time. for better or worse, we chose to look at unpublish first. when we announce updates to the name dispute policy we'll host an issue just like this one to talk about it.