Re: [rust-dev] On the use of unsafe

It seems natural to conflate memory (to which "unsafe" refers to uses of) and types. It might make sense to extend the terminology to types: perhaps "bottom" could express a similar thing: that beyond which the compiler is uncertain. However, if we tried to extend this terminology directly into h

Re: [rust-dev] On the use of unsafe

* Matthieu Monrocq: > If a method requires a SQL-safe string... ah no, don't do that, use > bind-parameters and you are guaranteed to be sql-injection safe. Sometimes, SQL queries (with parameter placeholders) are loaded from configuration files, and such operations look unsafe from the point of

Re: [rust-dev] On the use of unsafe

I'm not talking about unsafe fields. (maybe I gave that impression? Sorry.) That's how it is defined in the manual, sure, but the language is changing :) Anyway, as mentioned before we don't need to use `unsafe` for non-memory safety guarantees, if we define anothe attribute that genericises it.

Re: [rust-dev] On the use of unsafe

On 22/09/14 06:45 PM, Manish Goregaokar wrote: > As Chris mentioned, it's not about using the type system to create > safety. We're assuming that exists, the idea is to gate unchecked access > to the data (which /is/ required for libraries created for generic use) > with the `unsafe` keyword. Howev

Re: [rust-dev] On the use of unsafe

On Mon, Sep 22, 2014 at 3:45 PM, Manish Goregaokar wrote: > As Chris mentioned, it's not about using the type system to create safety. > We're assuming that exists > The sort of safety I'm describing does not exist in Rust whatsoever AFAIK. The very specific approach I'm referring to depends on

Re: [rust-dev] On the use of unsafe

As Chris mentioned, it's not about using the type system to create safety. We're assuming that exists, the idea is to gate unchecked access to the data (which *is* required for libraries created for generic use) with the `unsafe` keyword. However, many seem to be of the opinion that `unsafe` is jus

Re: [rust-dev] On the use of unsafe

On Mon, Sep 22, 2014 at 2:15 PM, Daniel Micay wrote: > I think it can be solved by using visibility, along with providing a way > to override the visibility rules and call private functions. That means > replacing the current usage of visibility for memory safety with unsafe > fields though, but

Re: [rust-dev] On the use of unsafe

On 22/09/14 05:12 PM, Tony Arcieri wrote: > On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay > wrote: > > Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It > uses `unsafe` as a memory safety boundary, and in this case breaking the > inv

Re: [rust-dev] On the use of unsafe

On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay wrote: > Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It > uses `unsafe` as a memory safety boundary, and in this case breaking the > invariant would be memory unsafe. I just want to say that I completely agree with you that

Re: [rust-dev] On the use of unsafe

On 22/09/14 03:21 PM, Chris Morgan wrote: >> It's completely unnecessary actually. > Would that it were. There was a time when I believed it was, but it's not. > >> If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref and would > be

Re: [rust-dev] On the use of unsafe

> It's completely unnecessary actually. Would that it were. There was a time when I believed it was, but it's not. > If a method requires a XSS-safe string, then it should take the XssSafeString parameter, which would implement Deref and would be built from a String by a method performing the nece

Re: [rust-dev] On the use of unsafe

On Mon, Sep 22, 2014 at 9:40 AM, Matthieu Monrocq < matthieu.monr...@gmail.com> wrote: > If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref and would be > built from a String by a method performing the necessary escaping. > This

Re: [rust-dev] On the use of unsafe

This had to do with XSS-proofing templates, which is a bit different and requires compile time magic. I've seen people concatenate strings while using prepared PDO queries in PHP -- nonnegotiable safety built in to the library is much better. This can't be handled with a type system. -Manish Goreg

Re: [rust-dev] On the use of unsafe

It's completely unnecessary actually. If a method requires a XSS-safe string, then it should take the XssSafeString parameter, which would implement Deref and would be built from a String by a method performing the necessary escaping. If a method requires a SQL-safe string... ah no, don't do that

Re: [rust-dev] On the use of unsafe

> That's not how Rust defines `unsafe`. It's open to misuse, and the > compiler will happily point out that it's not being used correctly via > the unnecessary unsafe lint. > If that's the case, do you think there's some worth in allowing the programmer to define arbitrary generic safety types? E

Re: [rust-dev] On the use of unsafe

On 21/09/14 04:27 PM, Evan G wrote: > Personally, I feel "safety" generalizes pretty well to "any concept > that should be called out explicitly as unsafe"--not just memory > safety. That's not how Rust defines `unsafe`. It's open to misuse, and the compiler will happily point out that it's not be

Re: [rust-dev] On the use of unsafe

On Sep 21, 2014, at 1:27 PM, Evan G wrote: > Personally, I feel "safety" generalizes pretty well to "any concept > that should be called out explicitly as unsafe"--not just memory > safety. The difference is that the current uses of `unsafe` are guarding things that cause a program to not have

Re: [rust-dev] On the use of unsafe

On 21/09/14 16:27 -0400, Evan G wrote: Personally, I feel "safety" generalizes pretty well to "any concept that should be called out explicitly as unsafe"--not just memory safety. You can feel that all you want, but memory safety is reasonably straightforward to define in a general context, wh

Re: [rust-dev] On the use of unsafe

Personally, I feel "safety" generalizes pretty well to "any concept that should be called out explicitly as unsafe"--not just memory safety. On Sun, Sep 21, 2014 at 4:12 PM, Daniel Micay wrote: > On 21/09/14 05:57 AM, Simon Sapin wrote: >> On 21/09/14 07:34, Daniel Micay wrote: >>> It's not inten

Re: [rust-dev] On the use of unsafe

On 21/09/14 05:57 AM, Simon Sapin wrote: > On 21/09/14 07:34, Daniel Micay wrote: >> It's not intended to be used for anything other than memory safety. > > It’s also used to maintain invariants, such as the bytes inside a String > being valid UTF-8: String::push_bytes() is unsafe, but > String::p

Re: [rust-dev] On the use of unsafe

On 21/09/14 07:34, Daniel Micay wrote: It's not intended to be used for anything other than memory safety. It’s also used to maintain invariants, such as the bytes inside a String being valid UTF-8: String::push_bytes() is unsafe, but String::push_str() is not. -- Simon Sapin __

Re: [rust-dev] On the use of unsafe

On Sun, Sep 21, 2014 at 2:02 AM, Cameron Zwarich wrote: > 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

Re: [rust-dev] On the use of unsafe

On Sep 20, 2014, at 11:29 PM, Tony Arcieri 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 i

Re: [rust-dev] On the use of unsafe

Also, here's a paper that provides a formalized definition of security domains using dependent types: https://research.microsoft.com/en-us/um/people/nswamy/papers/gradual-typing-embedded-securely-in-javascript-draft.pdf Would love to see Rust get dependent types eventually... but hey, I get it, g

Re: [rust-dev] On the use of unsafe

I'd also note: having a way of calling out these sorts of cases explicitly is enormously beneficial to code reviewers. It provides an easily greppable way to find where to focus their attention. I assume it would be beneficial for static analysis tools as well. On Sun, Sep 21, 2014 at 1:39 AM, Ton

Re: [rust-dev] On the use of unsafe

On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay wrote: > It's not possible to represent the semantics of 'insecure' in the > language as > that's very poorly defined and varies across domains and libraries. I'd define it as "think before you use this" -- Tony Arcieri ___

Re: [rust-dev] On the use of unsafe

On 21/09/14 02:29 AM, Tony Arcieri wrote: > Traditionally in Rust, "unsafe" has centered around memory safety. The > reference manual describes it as such: > > http://doc.rust-lang.org/rust.html#unsafety > > At Strange Loop, during Chris Morgan's talk, someone asked about using > the type system

[rust-dev] On the use of unsafe

Traditionally in Rust, "unsafe" has centered around memory safety. The reference manual describes it as such: http://doc.rust-lang.org/rust.html#unsafety At Strange Loop, during Chris Morgan's talk, someone asked about using the type system to present SQL injection after he described using the ty