How do (long held) security concerns in Python’s `pip` relate to Julia’s `Pkg`?

Internals & Design
1

I’ve learned that, for a while, folks have noted some security concerns with Python’s pip because packages can execute code arbitrarily on install.

I believe Julia’s Pkg can also execute code arbitrarily on install through the build step, right? Is there a similar concern with arbitrary code execution in Pkg? Or has this issue somehow been addressed?

2

The Pkg.build step is somewhat deprecated, I think very few packages use it nowadays, also to promote immutability of packages directories. But in the end, why worrying about arbitrary code run during the build step if the package you’re going to install can also run arbitrary code?

2 Likes
3

But in the end, why worrying about arbitrary code run during the build step if the package you’re going to install can also run arbitrary code?

Ah didn’t know that about Pkg.build, good to know.

But in the end, why worrying about arbitrary code run during the build step if the package you’re going to install can also run arbitrary code?

Agreed, that makes sense. But I do see Python folks worrying about this. Now I’m curious why.

4

I mean, it is indeed nice to avoid extra steps which can do anything during the installation process. If Julia was able to just drop Pkg.build (not possible within the 1.x series), package directories could be made completely read-only and could be checked for integrity with the git-tree-sha1. I’m not sure that’s done at the moment, since Pkg.build can potentially write to the deps/ directory. For example, the pull request Require Julia 1.6+, use Preferences, eliminate mutable state by staticfloat · Pull Request #189 · JuliaMath/FFTW.jl · GitHub removed the need to run Pkg.build for FFTW.jl, making the package immutable and more precompilation-friendly.

Regarding Python packaging, I don’t know if they have other options at all?

1 Like