On Sat, Apr 6, 2013 at 1:14 AM, Grant Husbands <[email protected]>wrote:
> To some extent, yes. I'm not familiar enough with Rust's lint modes to say
> much more than that. I'm going to try using Rust for a while before giving
> a more detailed proposal.
>
> However, I will give a more concrete example, now that I know slightly
> more. In servo.rc (in the servo project), there's a line like this:
> extern mod stb_image;
>
> I want to be able to write it something like this:
> extern mod rust-jpeg ( nogc, safe );
>
> Doing so should ensure that the library cannot do GC or anything directly
> or indirectly unsafe (alternatively, it should import the version that was
> compiled that way). Then, the servo project can be sure that rust-jpeg
> cannot perform any unsafe operations (or GC), without manual audits of its
> imports or code. It essentially removes the JPEG library from the TCB
> (trusted computing base) of Servo. Carefully applied, it would make servo
> much more secure against maliciousness via supporting libraries.
>
> The important thing, to my mind, is that I don't have to audit the
> rust-jpeg library at all, and the worst it can do (probably) is a denial of
> service. If this became standard practice for Rust code, it would be a
> systems language in which it's feasible to easily include relatively
> untrusted third-party libraries, securely, and interact with them
> naturally. I think there's a lot of mileage in that.
>
> Grant.
>
>
SafeHaskell might be a relevant example of prior art here (at least
regarding the nothing-unsafe half of the above). Much like Rust, Haskell
has a strong static type system, but with escape hatches (unsafePerformIO,
unsafeCoerce, most things involving the FFI) which can subvert it if used
improperly or maliciously, as with unsafe { } in Rust.
The approach SafeHaskell takes is that safety is tracked at the module
level, with three classifications: Unsafe, meaning that the module exposes
an interface which can violate safety; Trustworthy, meaning that the module
imports Unsafe modules, but the author of the module asserts that they are
only used in ways that are safe, and that the module does not outwardly
expose any way to violate safety; and Safe, meaning that the module
transitively imports only Safe and Trustworthy modules. These can either be
declared by the module author, where in the case of Safe the compiler will
verify that it's true, or otherwise the compiler will infer Safe or Unsafe.
It's up to the system administrator to set policy regarding trusted
packages. Essentially, if a package is marked as trusted, Trustworthy
modules in the package will be treated as being Safe, otherwise they will
be treated as being Unsafe. If you try to compile something while requiring
it to be safe, and it imports Trustworthy modules from untrusted packages
(or of course actual Unsafe modules), the compiler will complain and refuse
to compile it.
Basically, using the term from your email, the "trusted computing base"
requiring human inspection would consist of the modules marked Trustworthy.
>
>
> On Thu, Apr 4, 2013 at 10:39 PM, Niko Matsakis <[email protected]> wrote:
>
>> It sounds to me like you're talking about something similar to the
>> current lint modes for GC etc?
>>
>> Niko
>>
>
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
>
--
Your ship was destroyed in a monadic eruption.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
