Interesting slides! Thanks!

`pip download --no-deps` allowing arbitrary code-execution is non-obvious, and IMO broken.

Even pip install allowing arbitrary code-execution is non-obvious, although perhaps not entirely broken.

Does it matter if the code-execution happens at `pip install` or `python myapp.py`? Using 3rd party libraries inevitably means you're allowing code-execution to 3rd parties, that's the point after all.

Yes, because you could in theory run `pip install`, then manually read through every file you've just downloaded, then run `python myapp.py`.

But every package manager seems to grant RCE to every installed package. I agree it's broken.

> Yes, because you could in theory run `pip install`, then manually read through every file you've just downloaded, then run `python myapp.py`.

This security model is utter nonsense because no one does this.

Replace "manually read through every file" with "run your security code scanner against every file" and it becomes less nonsense, but just as applicable.

In reality this really isn't how code scans are done, so it's still a little silly, but I could theoretically see something like this being a desire.

It becomes more applicable, not just as applicable.

> then manually read through every file you've just downloaded

pip download?

Which can also execute arbitrary code according to the slides above.

You're not being imaginative enough.

Evil Joe: Can you install this package in the system's python install? All users in the lab need it.

Naive Joe: Hm... Seems harmless enough enough. Let me just install locally and check if there aren't any setuid binaries in there

naivjoe:~ $ pip install --local getpwned

... checks all installed binaries look good ...

Naive Joe: Funny package name

naivjoe:~ $ sudo pip install getpwned

Naive Joe: Done!

Evil Joe: Thanks! evil laugh

Naive Joe: uh what's so funny?

Evil Joe: Nothing.

Careless, amateurish? Maybe. Obvious? Maybe not.