Hello!
I recently found myself in the situation of:
my-program
└ crate-foo
└ crate-bar
└ crate-abc
In my dependency tree, crate-foo depends on crate-bar, which in turn enables a feature on crate-abc causing it's build.rs to read from a random number generator, and embeds those random numbers into the compiled binary executable.
Their intention is using those random bytes as a secret seed for a Hash Collision DoS mitigation. I understand why this is done, but this is only effective if you can keep your binaries secret to the point that it would be safe to store passwords in them. Even though most orgs would consider it a bad idea to embed passwords, many do indeed have the means to keep their binaries sufficiently secret to the point they could.
There are downsides when a library enables this unconditionally however, because:
- My binaries are mostly distributed pre-compiled through package managers, meaning the binaries (and by extension the secret seed) are public knowledge.
- Distributions like Debian, Arch Linux, openSUSE, NixOS, [...] are trying to prove the absence of a build server compromise, by documenting the build environment to the point that anybody could bit-by-bit reproduce the compiled artifact from source code (proving the binary was truthfully compiled from the alleged source code). This needs a deterministic build (which Rust has by default), but doesn't work if any crate in the dependency tree embeds random bytes, and Debian is even planning to reject binaries like this from being included in stable releases.
- People who need to care about
SLSA threat "D" need to care if crate-foo is in their dependency tree. To my knowledge Reproducible Builds is currently not required by any SLSA level, but may become a requirement in the future. It is currently already mentioned by NIST Secure Software Development Framework (SP 800-218).
I know some crate that are known-bad with an unresponsive upstream, I think there would be value in flagging those crates in cargo audit with low or informal severity. This would make it easier for the author of crate-foo to make an informed decision, or make it easier for the author of my-program to figure out the root cause of their non-deterministic compile output (triaging this is easy for me, but a major obstacle for many people).
This is somewhat unique to Rust because Python/JavaScript doesn't compile binaries, and Go (to my knowledge) is too restrictive during build for any library to pull something like this.
What do you think? :)
Hello!
I recently found myself in the situation of:
In my dependency tree,
crate-foodepends oncrate-bar, which in turn enables a feature oncrate-abccausing it'sbuild.rsto read from a random number generator, and embeds those random numbers into the compiled binary executable.Their intention is using those random bytes as a secret seed for a Hash Collision DoS mitigation. I understand why this is done, but this is only effective if you can keep your binaries secret to the point that it would be safe to store passwords in them. Even though most orgs would consider it a bad idea to embed passwords, many do indeed have the means to keep their binaries sufficiently secret to the point they could.
There are downsides when a library enables this unconditionally however, because:
SLSA threat "D"need to care ifcrate-foois in their dependency tree. To my knowledge Reproducible Builds is currently not required by any SLSA level, but may become a requirement in the future. It is currently already mentioned by NIST Secure Software Development Framework (SP 800-218).I know some crate that are known-bad with an unresponsive upstream, I think there would be value in flagging those crates in
cargo auditwith low or informal severity. This would make it easier for the author ofcrate-footo make an informed decision, or make it easier for the author ofmy-programto figure out the root cause of their non-deterministic compile output (triaging this is easy for me, but a major obstacle for many people).This is somewhat unique to Rust because Python/JavaScript doesn't compile binaries, and Go (to my knowledge) is too restrictive during build for any library to pull something like this.
What do you think? :)