4 ms·
> could have been in any language Bingo. This was a highly motivated, targeted, and well planned compromise of the supply chain itself. And funnily enough, usi
by bostik 3y ago
> could have been in any language
Bingo. This was a highly motivated, targeted, and well planned compromise of the supply chain itself. And funnily enough, using a memory-safe language could have actually made it less likely for this to be detected.
There were symptoms showing up prior to the discovery, most prominently Valgrind errors in otherwise unrelated project builds. (ref: https://bugzilla.redhat.com/show_bug.cgi?id=2267598 https://bugzilla.redhat.com/show_bug.cgi?id=2267598)
- dwattttt 3y agoThe equivalents in memory safe languages raise more eyebrows. Segfault developing on a shared C codebase and it's a day ending with y. Segfault in a language that's meant to not let that happen? Or conversely if a patch turns up that's explicitly doing lots of unsafe things? That gets more scrutiny.
- bostik 3y agoPeople like to harp on software written in C, and often for very good reasons. A vocal minority of those then whip out their calling card, "should have used Rust!" As a result, there is a sentiment in the peanut gallery that "memory safe language == Rust". You are correct in that a segfault in a project written in memory safe language gets more scrutiny. But imagine for a moment what would have happened if the compiler guaranteed that those Valgrind-caught memory access violations could not have occurred in the first place? We got lucky, and the developers who wrote the actual backdoor were sloppy. They were aiming for sneakiness and evasion first, memory correctness would have likely been an afterthought. The next group tasked with a similar approach will know better.