Hacker News Reader

Comment by chadly | Hacker News Reader

These seem to be relatively good changes. I still think the reasons they outline for "unpublishing" (still not a word) are not compelling.

I would like to see an immutable package feed.

View on HN

Agreed. I don't think unpublish should even exist and it just creates all these scenarios full of subjective decisions that will help some and harm others.

If 1.0.0 was published and it has a serious bug, publish a new package with the bug fix. Let 1.0.0 alone forever.

If unpublish shouldn't exist, then neither should there be the ability to rename packages.

They could adopt Github's model, which seems to work well: when you rename something, the old name becomes an irrevocable redirect to the new name (at least, I think it's irrevocable, I haven't tested it), so all existing uses of the old name still work transparently.

I have broken GitHub links, I assure you they're not irrevocable. I transferred my project laughinghan/mathquill to its own organization, so the repo became mathquill/mathquill, and then forked it, unwittingly breaking all github.com/laughinghan/mathquill/* URLs: not commits obviously, but Issues, PRs, Commit Comments...my commit messages occasionally link to discussions in commit comments, all of which were broken. :(

Yes, you would need to publish a new version of the package with a different name. But the history of what happened (and consequently anyone depending on the old name) would be preserved.

Prohibiting unpublish wouldn't prevent those scenarios, only the subjective decisions.

The same scenarios would still happen, there just wouldn't be the opportunity to make the subjective call to help more and harm fewer by unpublishing.

So, if you accidentally publish a repo with sensitive information, you shouldn't be allowed to correct the mistake by removing the version and uploading a fixed version? That seems like a completely legitimate and compelling reason to allow unpublishing.

If you publish sensitive information (even if you immediately remove it), that sensitive info is compromised. All the "unpublish" feature does is lull users who don't know any better into a false sense of security (I don't need to reset any passwords, I unpublished it).

The linked post makes the point that if that repo was published for even a second, then the info may have, and probably has already been, copied by any number of people. Might as well leave it up as a reminder to change any of that info ASAP.

Sensitive information is not in a binary state of "public" or "private". There are no meaningful degrees of difficulty of access to "public" information.

Consider doxxing. Regardless of who you think is perpetrating it, we can all agree it's real and does real harm, right? Sometimes they're from hacking into people's accounts, but often they're from scouring the public Internet for information on a person and putting it together, making information that is technically "public" more accessible.

Even if you change the password you accidentally published, knowing your expired password tells me about the kind of password you're likely to use next and for your other services. Having to find someone who was mirroring NPM's firehose of new packages at just the right time is one more barrier to that.

Services that don't offer an automatic "unpublish" action require you to contact the service in order to remove packages completely, which, moving forward, is exactly what npm will require one to do if you don't realize your mistake within 24 hours.

Reply on news.ycombinator.com