[zyedidia]

I agree -- relying on Safe Rust's "guarantees" for security purposes is very likely to be problematic. To make the reasons concrete: for the last 4 years rustc has had a bug that allows writing transmute (arbitrary type conversion) without the use of unsafe: https://zyedidia.github.io/blog/posts/5-safe-transmute/. This is one of the 77 current open unsoundness bugs on the Rust issue tracker. To make this tenable you would probably have to use a separate language -- maybe some formally-verified minimal Rust-like language, and with different priorities from a people perspective.

[iudqnolq]

I am a bit skeptical this is a workable approach long term, but there is a project based on an attempt to enumerate all of Rust's soundness holes and use Rust's compiler infrastructure to detect and forbid them. They think that by erring on the side of forbidding valid code this is feasible. https://news.ycombinator.com/item?id=35501065

[deredede]

From the horse's mouth (article of the linked HN post):

> PL/Rust contains a small set of lints to block what the developers have deemed the most egregious "I-Unsound" Rust bugs. > [...] > Note that this is done on a best-effort basis, and does not provide a strong level of security — it's not a sandbox, and as such, it's likely that a skilled hostile attacker who is sufficiently motivated could find ways around it (PostgreSQL itself is not a particularly hardened codebase, after all).

They have extra lints to help you avoid what they deem the most common soundness bugs. They make no claims that there is a way to make this approach safe against an attacker.