Post #4029877

2026-07-22 12:39 UTC

Most security vulnerabilities have pretty common shapes. But we also have solutions to them: - Ambient authority! Mitigation: capability security - Confused deputies! Mitigation: capability security - Memory exploits: Mitigation: use memory safe languages (Rust and etc if you gotta go low level, though languages with a GC or etc are actually even *safer* because they don't have "unsafe" blocks of code) or use CHERI - Injection attacks: Use structured representations. Quasiquote or combinator templating is much safer than string templating, for example. Why are we speaking to our databases in sentences? Send them the AST of the query! - Bad crypto usage: Use standardized cryptography patterns There are a few others, but even if you just focus on the above, we can simply *eliminate* huge swaths of security issues.

Replies (1)

@ekuber@hachyderm.io 2026-07-22 15:28

@cwebber@social.coop Just one nitpick: pretty much every GCd language has mechanisms to interact with pointers and muck around with types. The same capabilities from Rust's unsafe are generally available (except for fully sandboxed VMs, but that's not a property of the language), and depending on the prevalence of native modules in an ecosystem, their use can be quite extensive. Go and Java tend to reimplement natively, Python tends to FFI, for example. This is not to discount the benefits of a GC, but rather to point out that in general people haven't argued that those languages *aren't* memory safe despite the existence of torn reads or specialized APIs that can cause memory safety. Something like invisicaps/Fil-C or WASM sandboxing of an application and its dependencies would be a more complete solution than what most runtimes provide, of course.

Open ##4029874