Hi everyone! I'm a software engineer at aiven.io. Even though we are doing quite well in terms of user and revenue growth, we are using monorepo with little appropriate tooling: make, Jenkins, and rpm-tools are our "best friends" for a big Python project. I've googled different queries and found pants that way. I hope that we could implement pants for our codebase to reduce the number of shell scripts, make files, groovy in Jenkins while making linters and tests faster. One obstacle in bringing pants to our codebase is that it comes in a form of a bootstrap script, which is not great from a security pov. I think that we would have no problems with pushing it, if it was packaged as rpm for Fedora, or, at least using the usual setuptools way (which allows to repackage it as rpm). Are there any changes planned?

Why is not great from a security pov?

there is a pypi version, that is what i use

While I personally trust pants team, nobody can dismiss the possibility of account takeover, PyPI security issues, etc. Building (an RPM; as we have everything based on RPM) from sources and storing it in a safe place looks like the safest choice for me (and most probably, for our security team).

im v ambivalent about using scripts from the interwebs, so i would agree on that front. Using a pip installable would still put the onus on your sec team to audit it, but it has the advantages that you can pin hashes and ofc its public/published so more likely that in the event of a bad actor messing with it, it would be noticed

Well, you download the script once only, right? Then check it in to version control. The bootstrap script then installs pants using pip anyway. So I don’t really see how using the pypi version directly would make any difference here..?

if you dont have something checking the hash of the script - the script could theoretically change

So you don’t trust your version control system?

ah i see - you are suggesting to check the script in

Yes, it is not required, of course, but it is suggested, also here: https://www.pantsbuild.org/v2.8/docs/installation#creating-the-launch-script

Yes, you are expected to check the

./pants

script in, and audit it. You are also free to modify it to add whatever security checks are appropriate.

Hey @full-advantage-95926, long time, no see 😂 @happy-kitchen-89482 a fat binary would be a cool distribution method, because it would make delivery really simple. But it doesn't solve a deeper problem on-demand tool downloads that might happen as you add backends and so forth. Pants in general wants to get things from the internet on-demand if there are cache misses, so if we get into a situation where security wants to prevent builders from having internet access, we probably need to work that out with them.

@happy-kitchen-89482 Another problem is that pants requires Python packages of specific versions (mostly). That means that even if we ship a standalone binary with an embedded interpreter we need to package about 31 Python packages into RPMs. This is sad. The bootstrap also relies on rustup, but I think this can be fixed by conditionally using system version of Rust-related tools.

You shouldn't need rustup unless you're developing pants itself. The normal use case should download pre-built native code in the pants wheel.

Yep, so the on-demand downloads are now expressed via lockfiles with hashes (for Python tools resolved from PyPI) or expected sha256 hashes (for binaries downloaded from a URL), and these are all configured in subsystems that we can introspect over. In fact, @curved-television-6568 recently added a

./pants help tools

that will enumerate all the tools. We could add information there that helps you manually validate those tools, or even add a way to pre-fetch them.

Indeed, it would be cool to support air-gapped setups out-of-the-box.