@reverseics Isn't the point of starting calc.exe to prove access to execve (or CreateProcessA in Windows, I think)? Doing it through a link would be somewhat misleading since it doesn't imply arbitrary RCE like CreateProcessA would.

@SwishSwushPow Debian does indeed use them for autopkgtests. The .crate is often uploaded unmodified as .orig.tar.gz to Debian.

This can also be seen here:
https://whatsrc.org/artifact/sha256:d079fc82140060c1c860e9bebd9d708a0fe414c634b7190bb8e934b652d5a96d

@SwishSwushPow curious: have you considered contributing your reviews to cargo-crev? :) is there anything missing in their tooling to make this easier for you?

@cy maybe it's time for gentoo to join Reproducible Builds? :) These security concerns have been proven to be very solvable for many years (by Arch Linux and Debian), even without having everybody compile their own compiler.

@xeiaso.net The crypto libraries in the Rust ecosystem tend to be fairly good. :)

But also as an counter example, about 10 years ago I found a python crypto library incorrectly wiring up the FFI code and accidentally having the _verify function always return true: https://github.com/saltstack/libnacl/pull/54

@SpaetzleGrab Could you post a screenshot of the pacman output?

@SpaetzleGrab On archlinux.org you can look up the package, then click on "View changes" to get to the git log, which usually documents what was changed and why. If you post the package names I can check, I recall recently quite a few packages needed to recompile because of dynamic linking and breaking changes in libxml2.

@boilingsteam that's pretty cool! are the absolute numbers available somewhere? since Arch doesn't keep track of how many users there are, maybe this could be the next best thing to get an idea of how many there might be (in the desktop space).

@gimkin change it to check_title(title: &str), the rest is fine as-is. `.clone()` does a memory allocation and memory writes, the borrow is extremly fast/cheap (and doesn't introduce much/any complexity in this case).

In the long run you'd change panic! to actual error handling, but for beginner excercises it's ok. Good luck!

@hcj Use archinstall until you're comfortable enough with the distro to do it manually (or just keep using the installer, we don't judge ✌️)

@wegegeld Linux distributions often have precompiled binaries you can use. If you're on Debian/Ubuntu, I recommend using homebrew in addition. If cargo is actually "downloading gigabytes" you're likely using a very old version of cargo, < Rust 1.68 released on 2023-03-09. If the binaries are massive, make sure you use `cargo build --release` for optimized builds and strip debug symbols (although I think this is now done automatically). I hope this helps.

Progress on securing our distribution against supply chain attacks: The Debian testing/trixie release on amd64 is now reproducible for over 95%, and counting. You can use the new debian-repro-status package to query the reproducibility status of your installed Debian packages. See https://reproduce.debian.net/ #debian #reproducible-builds

@stf @debian "Progress on securing [...]" idk, seems accurate to me

@stf @debian Reproducible builds is more of a "nothing up my sleeve" technique, and if multiple independent parties have successfully reproduced all your binaries, this means if there's a backdoor, you can find it by reading the source code (ignoring the trusting trust and collusion problem for now).

Reproducible builds is not that useful for "finding abuse", but "closing one vector for abuse in entirety". This kind of systemic improvement is extremely rare in computer security.

@stf @debian hello! I'm the developer of some of the mentioned tools and spent ~7 years in this space, so probably somewhat qualified to answer:

There is no "the one supply-chain security problem", it's multiple. Reproducible builds gives you guarantees about the binaries you put into your computer, it obviously doesn't fix the lack of source code review efforts. The Rust ecosystem has cargo-crev to defeat Jia Tan style attacks, but the overall opensource community doesn't.

@ams @debian I briefly looked into this, the official binary (---) has a "/usr/share/zoneinfo" string in .rodata that is missing in the reproduced binary (+++). I'm not sure why though. This causes a large number of followup offset differences (making the diff somewhat hard to read), they disappear automatically once the original issue is fixed however.

https://web.archive.org/web/20250504134943/https://reproduce.debian.net/amd64/api/v0/builds/271260/diffoscope

@scrum_log You're welcome! Also u64::saturating_add and u64::saturating_sub are incredibly useful.

@scrum_log if you specifically want this, use u64::wrapping_add, or u64::overflowing_add :)

@kushal If all keys are opaque you can use BTreeMap<String, Value> (or a more specific value-type if possible), but you can also make a catch-all by adding to your struct:

struct Person {
name: String,
lucky_number: u64,
#[serde(flatten)]
extra: BTreeMap<String, Value>,
}

@kushal yes, you likely want to make your own struct and put `#[derive(Serialize, Deserialize)]` on it - your regular code then builds on top of this struct definition and your only interaction with json is serde_json::{to_string, from_str}. :)

Reference: https://docs.rs/serde_json/1.0.140/serde_json/index.html#parsing-json-as-strongly-typed-data-structures