memorysafety
use a predictable and verifiable build toolchain
Really impressive what you have done so far.👍
Unfortunately it seems like you are using brittle build and development chains including Docker and a vaguely formulated readme (For dev build instructions)
I‘d recommend taking a look at nix or similar approaches.
I‘d be happy to hear your solutions to deterministic builds.
Given the goals of the org, I can see how a predictable and verifiable (as in SBOM) build toolchain would be an important factor.
Even then I still get the feeling that "use Nix, not what you do" comes off a rude fanboyish comment, in particular at this stage in sudo-rs' development.
Perhaps this should be re-phrased as "use a predictable and verifiable build toolchain for GA releases".
What exactly the authors (key contributors) end up using is up to them.
@hsjobeki There is Cargo.lock which is used to pin down specific version of deps, including their checksum.
@hsjobeki There is Cargo.lock which is used to pin down specific version of deps, including their checksum.
@NobodyXu, What about you build tools? Rustup, cargo, clang, etc. How deep do you want to pin versions? And thus reduce uncertainty? Maybe even down to the kernel version?
@NobodyXu,
What about you build tools? Rustup, cargo, clang, etc.
Rustup doesn't take part in compilation.
It's only there to manage cargo/rustc.
Clang and Gcc is indeed a problem, which is probably why this repo chose to use docker for compilation.
Ideally it's better to avoid pulling in C/C++ code at all as it makes audit much harder and also makes cross compilation much harder.
How deep do you want to pin versions? And thus reduce uncertainty?
Maybe even down to the kernel version?
The kernel does not affect the generated binary.
Sorry if my first comment seemed a little „fanboyish“ I hope you will still take a serious look at my suggested solution.
We only use docker to run the test suite and not to actually compile the project. Based on that, I don't see what would we win from using nix as we need to create users and configure the environment in a certain way to test some scenarios and AFAIK you cannot do this kind of stuff with nix as it is "just" a package management system (but I'd be happy to be corrected).
I feel this sort of overlaps with #255 as it is a comment on what's the "right build environment" for this project and I'd say the answer is sort of similar. We only suggest people use rustup as a convenient way to get a rust toolchain but you can use whatever means you want to install a "recent" enough toolchain.
@pvdrz nix is not just a package manager. If you read the description on their site. It says:
„ Reproducible builds and deployments. Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems.“
From my own experience i can say that the rust integration from nix is quite awesome and would fix #255. Also Highly reproducible test environments are a strength of nix. It is quite some work to understand everything from that ecosystem because they don't promote it overly. You can play a little bit around with their examples to get a rough feel how it works.
A short real story: A highly security relevant hypervisor vendor used nix to build their software. As nix hashes everything by default they immediately detected a single bit flip in one of the RAMs of their build host. As the final output hash differed from the pre-calculated one.
oh I know how nix works as I've used it before. That being said I don't see what we win from using it over docker right now as it doesn't allow us to setup the environment we need for our tests without affecting the host system.
Have you heard of „nixos Integration tests“?
It starts a qemu vm configured as you like. you can specify into every detail what services and how to configure/ users permissions etc. You can set kernel version or
Setting evironment variables is also included.
Here is an example how ‚sudo‘ is currently tested.
https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/sudo.nix
(unlike the name suggests you can use those tests outside of nixos monorepo)
Yeah, I think this is not going to happen.
The main reason is that most (all?) the contributors are already using the current set up to run tests. So changing this would mean that everyone would have to get used to it which outweighs any hypothetical benefit we might get from it.
Packaging sudo-rs to be used in nix is a completely different story but we're not at that stage yet so we're not having that discussion anytime soon.