Comment by qwertox | Hacker News Reader

Comment by qwertox | Hacker News Reader

I don't think that it's good to just delete the packages. Same goes for Android Apps in the Google Play Store or for Chrome Extensions.

These compromised packages should have their page set to a read-only mode with downloads/installs disabled, with a big warning that they were compromised.

This is specially troublesome with Chrome Extensions and Android Apps, where it is not possible to get to know if I actually had the extension installed, and if I had, what it was exactly about.

Chrome Extensions getting automatically removed from the browser instead of permanently deactivated with a hint of why they can't be activated again, and which was the reason why the extension got disabled, is a problem for me. How do I know if I had a bad extension installed, if personal data has been leaked?

This also applies to PyPI to some degree.

----

Eventually the downloads should get replaced with a module which, when loaded, prints out a well defined warning message and calls sys.exit() with a return code which is defined as a "vulnerability exception" which a build system can then handle.

There is the "Yank" PEP 592 semantic that can be used to mark vulnerable packages. It's adoption has been a little slow, but I agree, having these packages available and marked accordingly makes it easier for security scanning and future detection research.

https://www.python.org/dev/peps/pep-0592/

Even better would be allow their install, but to have them start up with an immediate panic() sort of function (i.e., print("This package has been found to be malicious; please see pypi/evilpackagename for details"); sys.exit(99)) to force aborts of any app using those packages.

python packages run arbitrary code at install/build time, so this isn't viable.

It's no longer arbitrary if the PyPI crew is the one who controls the code, or did I understand you wrong?

Just that it isn't as simple as adding the lines to when the code gets executed. I think I misunderstood you, instead of prepending the code you are suggesting the entire compromised package get replaced with `throw "You got Hacked"` at import time.

Correct, when the program starts to run and imports the modules, as nothing will make admins more aware that something is really wrong here. Maybe raise an exception which, if not handled, executes sys.exit() with a predefined code.

And some mechanism to detect this at install/build time as well, so that automated built systems can cleanly abort a build and issue a specific message which can then be forwarded via email or SMS through some custom code.

The entire package gets replaced by a standardized, friendly one. No harmful code gets downloaded.

Denial of Service by panicing is also harmful for some processes.

It's not like an already running process will be affected by this.

This would only occur when the package gets updated or reinstalled, which shouldn't happen without supervision if the program is running in a sensitive context.

Else a Denial of Service is a good last resort measure in order to prevent running a malicious service. Ideally this gets detected at install/build time.

.whl packages don't run arbitrary code, they're just zips.

Skimming through that link, it seems that `yank` is for pulling _broken_ packages, whereas the suggestion above is to explicitly mark them as malicious.

Should we call the "mark them malicious" version "Yeet" or "Yoink"?

`npm yeet malcious-package`

Good point. The keyword for uninstall and remove residual files should be Yeet indeed.

Downloading the latest, bleeding edge version should be Yoked

pip install yoked <package>

Reply on news.ycombinator.com