I agree. Still, it is very convenient and it’s definitely the right tradeoff in my case. Loads of Elixir libraries have ended up picking the same tradeoff (e.g. everything that uses RustlerPrecompiled, the default packages for Phoenix build-time tooles, etc.). I don’t remember if I have documented this yet, but you can use a local executable of z3, which you can install from wherever you want. However, I haven’t implemented a conditional test on this option, so the external z3 executable is downloaded anyway… Anyway, this is a problem I can solve in a future version.
This is exactly what I don’t want from an Elixir package. One of the things taht brought me to Elixir is the extremely hands off build tool (i.e. Mix), where you add stuff to a file and things just work. For the default configuration of this library, I want things to just work and security takes a back step. There is always a tradeof between security and convenience, and I am unappologetic going all the way to convenience for this specific library. I do respect your different tradeoffs.
So, I will NOT disable the possibility of downloading the Z3 binary from github, but I would certainly welcome a PR to do the following: 1) document the config options in a centralized place, 2) add a download_z3_executable: boolean() flag or some other equivalent option that disables the binary download, 3) adding a list of whitelisted hashes/signatures/whatever for the downloads so that the source can be checked (although if you’re not compileing Z3 itself, are you sure the hashes are safe? taking the hashes from the same website that hosts the code a bit too “security theatrical” for my tastes).
And if you allow me, I will go on a small rant… I am not sure that downloading a package from Hex is safer than downloading a release file from GitHub (can’t an attacker compromise the code hosted on Hex.pm? Can’t the Hex.pm team compromise it themselves?). It’s very easy to get all worked up with security stuff and supply chain attacks, but ultimately some form of trust is required, and the hard thing is to put that trust in the right place… IMO modern software needs to be seen as fundamentally insecure, especially when written in a high-level language like Elixir: you have elixir, which is compiled to erlang, which is interpreted by a large C program (the BEAM, which famously had/has a very serious SSL bug: Erlang/OTP ssl flaws let unauthenticated attackers crash DTLS and TLS 1.3 listeners | Mallory), which runs on top of a huge multi-language program (the OS) which runs in some hardware you’ve never seen that lives on a server farm handled by people you’ve never met… And, among all of this, we’re worried about a small compile-time script (that runs on the build machine and not necessarily on the production machine) that downloads a well known binary from a rather secure source repository?
The point of this rant is not to belittle your security concerns about my package, which I do respect. It’s just a somewhat nihilistic thought about the current state of software development: we have build a tower so high that no one can see the foundations. And I’m contributing to the problem by writing yet another wrapper to yet another language for an incomprehensibly complex piece of software (Z3) which I barely understand while trusting its outputs.