I mean, that’s not a Rust issue per se. It’s only noticeable because cargo is much better than most build systems, and hence is an actual option for distribution of software. But there should ideally always be a binary distribution. I know some people like to build everything by themselves, but I get it, it’s annoying.
For people who do this, is the purpose to ensure you are not getting a bad binary which has some malicious code compiled in?
If yes, isn’t it more difficult to check all the source code yourself? You may as well trust a binary where the author has confirmed a hash of the binary. Unless you really are checking every single line of source code. But then I wonder how you get anything else done.
The idea is that someone is checking the code. And by building it yourself, you can at least ensure that you’re getting what’s built from the code. It is possible that some malicious stuff was inserted while building the binary that doesn’t show up in the source code. Building from source solves that problem.
Reproducible builds try to solve that problem by generating some provenance from a third party. A middle ground can be building the binary using something like GitHub Actions, since that can be audited by others. That comes with its own can of worms since GH is owned by M$, but I digress.
So it is technically sane to do it, just not very practical in my view. But for lesser known apps, I do sometimes build from source.
The incident from xz gives a good example of where self-compiling stuff would be a good idea.
The code was mostly fine, but the maintainer managed to include malicious instructions in the binary. Most people who read the source, didn’t realise the possibility. I checked it out afterwards and it was still hard to get.
Yeah, the good tooling also means it isn’t even terribly difficult for the dev to provide builds, but it isn’t quite as automated as publishing to crates.io, so many don’t bother with automating or manually uploading…
Okay so, this is less a line in the sand and more a 14 foot concrete wall topped with razor wire and guarded by marines with rifles with fixed bayonets in the sand:
I will not install an end-user application using Cargo, and I will say many mean things to anyone who suggests it.
Python’s Pip or Pypi or PyPy whichever it is (Both of those are the names of two different things and no one had their head slammed into a wall for doing that; proof that justice is a fictional concept) I can almost accept. You could almost get me drunk enough to accept distributing software via Python tooling, because Python is an interpreted language, whether you ship me your project as a .exe, a .deb, a flatpak, whatever, you’re shipping me the source code. Also, Python is a pretty standard inclusion on Linux distros, so Pip is likely to be present.
Few if any distros ship with Rust’s toolset installed, and the officially recommended way to install it, this is from rust-lang.org…is to pipe curl into sh. Don’t ask end users to install a programming language to compile your software.
Go ahead and ask your fellow developers to compile your software; that’s how contributing and forking and all that open source goodness should be done. But not end users. Not for “Install and use as intended.” For that, distribute a compiled binary somehow; at the very least a dockerfile if a service or an appimage if an application. Don’t make people who don’t develop in Rust install the Rust compiler.
The C example is the wonderful happy path scenario that only manifests in dreams.
Most projects don’t have a dependency list you can just install in a single apt command. Some of those dependencies might not be even available on your distro. Or there is only a non-compatible version available. Or you have to cast some incantation to make that dependency available.
Then you have to set some random environment variables. And do a bunch of things that the maintainers see as obvious since they do it every day, so it’s barely documented.
And once you have it installed, you go to run it but discover that the fantastic CLI arguments you found online that would do what you installed this program to do, are not available in your version since it’s too new and the entire CLI was reworked. And they removed the functionality you need since it was “bad practice and a messy way to do things”.
All of this assuming the installation process is documented at all and it’s not a “just compile it, duh, you should know how to do it”.
Then why do you need cargo in the first place, sir? You install a program written i Rust just as if it isn’t. When you apt install xzy, you don’t even know what language is used to program it.
I don’t think it is the distro’s responsibility or the developer’s responsibility. I think it is up to a volunteer whether they package it for the distro, or up to you as the consumer to install it on your own, or find a distro with more packages.
The developer is only supposed to share his code. It’s the distro’s responsibility to provide binary build of famous programs so that most users don’t have to compile. When they don’t, it’s inevitable that individual users have to build it themselves. This has been the norm for decades.
If you tell me to install an end-user facing application with a programming language’s package manager, I’m out. Like, Adafruit was at one point recommending a Python IDE for their own implementation of micropython called Mu, and the instructions were to install it with Pip. Nope. Not doing that.
I live programs written in rust. They are quick & lightweight & fun.
Know what i hate ? Installing rust programs with cargo. It’s slow & grinds my Chromebook to a halt.
I mean, that’s not a Rust issue per se. It’s only noticeable because
cargois much better than most build systems, and hence is an actual option for distribution of software. But there should ideally always be a binary distribution. I know some people like to build everything by themselves, but I get it, it’s annoying.For people who do this, is the purpose to ensure you are not getting a bad binary which has some malicious code compiled in?
If yes, isn’t it more difficult to check all the source code yourself? You may as well trust a binary where the author has confirmed a hash of the binary. Unless you really are checking every single line of source code. But then I wonder how you get anything else done.
The idea is that someone is checking the code. And by building it yourself, you can at least ensure that you’re getting what’s built from the code. It is possible that some malicious stuff was inserted while building the binary that doesn’t show up in the source code. Building from source solves that problem.
Reproducible builds try to solve that problem by generating some provenance from a third party. A middle ground can be building the binary using something like GitHub Actions, since that can be audited by others. That comes with its own can of worms since GH is owned by M$, but I digress.
So it is technically sane to do it, just not very practical in my view. But for lesser known apps, I do sometimes build from source.
The incident from
xzgives a good example of where self-compiling stuff would be a good idea.The code was mostly fine, but the maintainer managed to include malicious instructions in the binary. Most people who read the source, didn’t realise the possibility. I checked it out afterwards and it was still hard to get.
Yeah, the good tooling also means it isn’t even terribly difficult for the dev to provide builds, but it isn’t quite as automated as publishing to crates.io, so many don’t bother with automating or manually uploading…
Okay so, this is less a line in the sand and more a 14 foot concrete wall topped with razor wire and guarded by marines with rifles with fixed bayonets in the sand:
I will not install an end-user application using Cargo, and I will say many mean things to anyone who suggests it.
Python’s Pip or Pypi or PyPy whichever it is (Both of those are the names of two different things and no one had their head slammed into a wall for doing that; proof that justice is a fictional concept) I can almost accept. You could almost get me drunk enough to accept distributing software via Python tooling, because Python is an interpreted language, whether you ship me your project as a .exe, a .deb, a flatpak, whatever, you’re shipping me the source code. Also, Python is a pretty standard inclusion on Linux distros, so Pip is likely to be present.
Few if any distros ship with Rust’s toolset installed, and the officially recommended way to install it, this is from rust-lang.org…is to pipe curl into sh. Don’t ask end users to install a programming language to compile your software.
Go ahead and ask your fellow developers to compile your software; that’s how contributing and forking and all that open source goodness should be done. But not end users. Not for “Install and use as intended.” For that, distribute a compiled binary somehow; at the very least a dockerfile if a service or an appimage if an application. Don’t make people who don’t develop in Rust install the Rust compiler.
cargo install xyzandapt install xyzaren’t mutually exclusive.Average C from source experience: (copied from Kicad)
apt get long list of dependency git clone cd cmake make sudo make install rm -r .Average Rust from source experience:
Most of the time you should probably not install from source of possible.
The C example is the wonderful happy path scenario that only manifests in dreams.
Most projects don’t have a dependency list you can just install in a single apt command. Some of those dependencies might not be even available on your distro. Or there is only a non-compatible version available. Or you have to cast some incantation to make that dependency available.
Then you have to set some random environment variables. And do a bunch of things that the maintainers see as obvious since they do it every day, so it’s barely documented.
And once you have it installed, you go to run it but discover that the fantastic CLI arguments you found online that would do what you installed this program to do, are not available in your version since it’s too new and the entire CLI was reworked. And they removed the functionality you need since it was “bad practice and a messy way to do things”.
All of this assuming the installation process is documented at all and it’s not a “just compile it, duh, you should know how to do it”.
I try not to build from source often. My computer is a potato.
Then why do you need cargo in the first place, sir? You install a program written i Rust just as if it isn’t. When you
apt install xzy, you don’t even know what language is used to program it.And if the developer only publishes the source?
That’s your distro’s problem, not the developer’s
I don’t think it is the distro’s responsibility or the developer’s responsibility. I think it is up to a volunteer whether they package it for the distro, or up to you as the consumer to install it on your own, or find a distro with more packages.
What if the developer of this C program only publishes the source code? Evil?
I think that’s valid as well.
OK, apologies, I’ll stop taking weird.
The developer is only supposed to share his code. It’s the distro’s responsibility to provide binary build of famous programs so that most users don’t have to compile. When they don’t, it’s inevitable that individual users have to build it themselves. This has been the norm for decades.
It has been, but it does seem like that’s starting to change
The distro does provide it, but I wouldn’t say they are responsible for it, unless you are paying them. Otherwise that sounds like entitlement.
As a consumer sometimes you just have to install from source. Not everything is always in apt.
If you tell me to install an end-user facing application with a programming language’s package manager, I’m out. Like, Adafruit was at one point recommending a Python IDE for their own implementation of micropython called Mu, and the instructions were to install it with Pip. Nope. Not doing that.
Me: I wanna try this node program, how do I install it?
Node: Well first you need to download these 100 node packages using your system package manager before you can use my package manager.
Me: And then I can install node packages at the user-level?
Node: Oh you poor sweet summer child. At the directory-level, of course!
Me: Oh okay. Is… is all this highly necc-
Node: It’s better this way.
Annoyed Maintainer: fine, here’s a Docker file. Stop filing bugs about how you can’t install node.
Try
cargo-binstallI’ll look it up. I’m guessing it install app images?
I’d guess just binary builds, no need to reinstall the entire environment again every time you install something.