Quite impressive, I did not know so many bugs were due to memory access.
Rust at Scale: An Added Layer of Security for WhatsApp
11–20 of 151 posts
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#12> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...].
They don't say what they did about it, do they? Did they just accept it?
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#13> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...]. They don't say what they did about it, do they? Did they just accept it?
The whole article a bit watery which is why I read it as a PR rather than technical presentation
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#14Earlier quoted context omitted.
Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.
It doesn't make sense for that device alone, but the vendor probably supplies all the different equipment in the gym. Using a tablet simplifies their supply chain, deployment, debugging/repair, app update process and simply supports more features. There are probably some connectivity features on the device, for example. When you look at all of that together, it's hard to argue it's wasting money. It's like complainin…
Well, doesn't look like to me, and a plain ESP32 with a touch screen would do the job for displaying a weight bar with plus, minus and reset count buttons.
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#15[flagged]
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#16Cool - now we only need to get selling-you-out-for-profit-Zuckerberg out of WhatsApp to make it really trustworthy.
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#17> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...]. They don't say what they did about it, do they? Did they just accept it?
Probably yes. It's ~300KB per binary, and it's a one-time cost.
It can be avoided entirely by disabling the standard library, but that's inconvenient, and usually done only when writing for embedded devices.
Usually the problem isn't the size directly, but duplication of Rust dependencies in mixed C++/Rust codebases.
If you end up with a sandwich of build systems (when you have library dependencies like C++ => Rust => C++ => Rust), each Rust/Cargo build bundles its copy of libstd and crates. Then you need to either ensure that the linker can clean that up, or use something like Bazel instead of Cargo to make it see both Rust and C++ deps as part of a single dependency tree.
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#18Earlier quoted context omitted.
It doesn't make sense for that device alone, but the vendor probably supplies all the different equipment in the gym. Using a tablet simplifies their supply chain, deployment, debugging/repair, app update process and simply supports more features. There are probably some connectivity features on the device, for example. When you look at all of that together, it's hard to argue it's wasting money. It's like complainin…
Well, doesn't look like to me, and a plain ESP32 with a touch screen would do the job for displaying a weight bar with plus, minus and reset count buttons.
And then you get to a cardio unit where you want a completely different set of features and have to start over. Going lean on hardware only makes sense when you push out a very high number of units, when you have to deal with battery constraints or when you just have a lot of intertia, the combination of existing codebase and developer filter skillset.
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#19> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...]. They don't say what they did about it, do they? Did they just accept it?
Who knows what they did, but there are things which can be done: https://github.com/johnthagen/min-sized-rust
Re: Rust at Scale: An Added Layer of Security for WhatsApp
#20The hardest part of a rewrite like this is usually maintaining bug-for-bug compatibility with the legacy parser rather than the actual Rust implementation. Most real-world media files are malformed in some way that the C++ code implicitly handled, so if you write a strict parser you end up breaking valid user data. Differential fuzzing seems like the only practical way to map that behavior without manually reviewing…
It sounds like it's a design goal of this "wamedia" to _not_ maintain bug compatibility with media players.
I suspect it is actually about maintaining permissiveness for malformed inputs rather than keeping security bugs. I ran into this building ingestion for a print-on-demand service where users upload technically broken PDFs that legacy viewers handle fine. If the new parser is stricter than the old one you end up rejecting files that used to work, which is a non-starter for the product.