On Sep 20, 2014, at 11:29 PM, Tony Arcieri <basc...@gmail.com> wrote:
> He suggested using unsafe to call out when a SQL query is being made with a > raw string. > > On the one hand I really liked the clarity of calling out passing a raw > string to a SQL driver as being inherently unsafe, but on the other hand it > seems to be semantically different from Rust's traditional sense of what's > unsafe. > > Is it ok to extend unsafe to things which are unsafe from a security > standpoint, or is this conflating concerns? > > Should there be a standard way to express things which are potentially unsafe > from a security standpoint but not necessarily from a memory safety > standpoint? The usual solution to this particular problem in typed languages is to make a new type wrapping sanitized strings, use some feature of the language (e.g. abstract types or module privacy) to restrict the creation of instances of this new type, and expose functions that produce an instance of this type by sanitization. I think that this is a better use of the language than using ‘unsafe’ in a confusing and unidiomatic way. Rust doesn’t really provide any specific features for security beyond memory safety, but it should be possible to extend the language to support things like information-flow security, etc. Cameron _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
