@snaggen@programming.dev to Rust@programming.dev • 8 months agoSecurity advisory for the standard library (CVE-2024-24576)blog.rust-lang.orgexternal-linkmessage-square10fedilinkarrow-up150arrow-down11cross-posted to: security@lemmy.mltechnology@lemmy.world
arrow-up149arrow-down1external-linkSecurity advisory for the standard library (CVE-2024-24576)blog.rust-lang.org@snaggen@programming.dev to Rust@programming.dev • 8 months agomessage-square10fedilinkcross-posted to: security@lemmy.mltechnology@lemmy.world
minus-square@Schmeckinger@feddit.delinkfedilink1•8 months agoBut there is no reason to use a script, when you have a build.rs anyways. Since pretty much everything the script can do build.rs can do better.
minus-square@sugar_in_your_tea@sh.itjust.workslinkfedilink3•edit-28 months agoThat’s not going to be particularly feasible when generating bindings and other complex build processes. For example, the Qt bindings run shell commands as part of the build.rs. As does gettext-rs. So I don’t think it’s unreasonable to think a developer could sneak in an exploit with “temporary code” to improve some part of the build process on Windows.
But there is no reason to use a script, when you have a build.rs anyways. Since pretty much everything the script can do build.rs can do better.
That’s not going to be particularly feasible when generating bindings and other complex build processes. For example, the Qt bindings run shell commands as part of the build.rs. As does gettext-rs.
So I don’t think it’s unreasonable to think a developer could sneak in an exploit with “temporary code” to improve some part of the build process on Windows.