Discussion: Replacing packages raises security concerns

[idleberg]

I have recently come across an issue in the package_control repository that got me worried. Apparently, there have been cases where a package has been replaced with another one (example). Ultimately, this leads to a user's package being replaced on his computer without warning or any means to accept/object this. My main concern is security, but of course there are other reasons why one might not want this (file under ”user habits”).

Some random thoughts:

As a developer who gets tired of maintaining a package, I'd love to see my work live on under somebody else's care, no question. The same is probably true for many users of my package. I can hand over my repository to somebody else and nobody will ever notice.

If I have malicious intent, I can try to build a package that people love and install. And then boom, replace it with something that steals or destroys data. Maybe the maintainers of this repository will react in time and remove the package from the channel, but chances are the threat is unnoticed for some time. When somebody chooses your package, it's usually under highly subjective criteria. One thinks one chooses the right package because it's popular, either through the number of downloads or stars on GitHub, or one ”knows” the developer through other work.

Right, no question.

However, I think replacing a package with a fork or a similar, actively maintained package is something different. I don't know the ”best” way to handle this, but since I'm maintaining packages for several other editors, I know how others are doing it. So far, I like VSCode's approach the best. The process itself is a bit unelegant: one has to open an issue and announce the deprecation of his package. Optionally, one can propose an actively maintained fork or some other package. Users of the package can then choose whether they want to switch to the new package or continue using the deprecated one. Also, deprecated packages can no longer be installed (manual installation, e.g. git clone is an exception, of course). Most users will probably choose the new package without looking at it, and that's probably fine. However, an individual or an organization to whom security is important gets the opportunity to review the new package, then install it. They probably do the same with any update.

What if an author's interest in his package is re-awakened by a new package that has taken its spot? He has no chance to win back the audience he potentially built over years. In an ideal world, the two authors maintain a package together. But that's not for everyone. And competition isn't necessarily a bad thing, is it?

Could there be a user-driven mechanism that helps fade out an unmaintained package, so that it's still available but less prominently featured on the website, if not hidden altogether from search results?

Anyway, I wanted to bring this up and since discussions aren't enabled in this repo, I posted my concern as an issue. Would love to hear your thoughts!

[braver]

Apparently, there have been cases where a package has been replaced with another one

Yes, this happens all the time.

Also, any changes and new releases to an existing package are not reviewed here. Any package may later on change course, through various means, and potentially add "malicious" code. There are examples of that too. A package or repo does have to change hands for that too happen.

Replacement of a package is actually the only thing that is reviewed at all (we tend to check the new package although not necessarily very thoroughly). Of all the ways a package might turn malicious the replacement procedure is actually the safest and least likely one.

Additionally, since we tend to review replacements, if a package's content significantly changes we always recommend messaging existing users and telling them how they can (manually) install and freeze an older version if they want to. Again, even this is not limited or specific to replacements, it happens quite regularly that packages are rewritten and have major version number releases and feature changes that not everyone likes (or they need to manage the timing of). I have seen several of such situations and it tends to work out just fine. I don't feel there is a need for an engineering-based solution (built into the package control system). For one because the communication-based solution is working. For another because there are no engineers available to build such a solution (we're not Microsoft or even any kind of business).

What if an author's interest in his package is re-awakened by a new package that has taken its spot?

We give authors some time (at minimum 2 weeks, in practice typically several months) of fair warning. If you want to guard your spot, keep your package updated and read your mail. Beyond a certain point we can't, and don't need to, do more.

In an ideal world, the two authors maintain a package together.

This is always our preferred and recommended solution, it's not always possible though.

In the end, if you're concerned about security via this path, do not use package managers. Also do not use NPM, Homebrew, Pip, etc. etc. The same vulnerability is everywhere and inherent to the idea of a package manager (assuming not every new tag of a package is manually reviewed, scanned and tested by third parties).

But that's besides the point. Yes, there is a security risk. But no, It is not limited or particular to the replacement process.

I'm going to close this because it's not actionable and doesn't raise anything new. All of this has come up before and will do so again at some point, and that's good. Discussion is good, so thank you for that. And I'll keep an eye on this so feel free to ask more questions or whatever, it's all good 👍🏻

[dentarg]

Thanks for the reply @braver. I've recently been thinking about this more myself. While more inconvenient, I'm going to stop using Package Control, as I want to verify the updates to the packages I'm using.

In the end, if you're concerned about security via this path, do not use package managers. Also do not use NPM, Homebrew, Pip, etc. etc. The same vulnerability is everywhere and inherent to the idea of a package manager (assuming not every new tag of a package is manually reviewed, scanned and tested by third parties).

While this is true, there are differences. I do put a bit more trust in Homebrew: every update to a package/formula is merged by the Homebrew maintainers. It is just not pulled directly from the individual source of the package that they submitted one time (perhaps long ago). The Homebrew project is also a lot bigger in audience so I put some trust in that the updates are more scrutinised.

Re: Python, npm and RubyGems, there are on-going efforts about signing packages, see for example the proposal to RubyGems: rubygems/rfcs#37. I believe an effort like this would cover a package being replaced.

I'll also point out that it is not common at all for a particular Ruby gem to be replaced with another, it is a diligent process that needs to take place: https://blog.rubygems.org/2022/01/19/rubygems-adoptions.html. It seems similar for npm: https://docs.npmjs.com/policies/disputes