[rust-dev] Library Safety

Grant Husbands rust-dev at grant.x43.net
Wed Apr 3 13:22:56 PDT 2013


I've now read through the mentions of effect systems and indeed I am
talking about something simpler that doesn't require either function
granularity or inference. As Matthieu Monrocq notes it mostly amounts to
restrictions of imports and probably parse-time restriction of particular
constructs over a whole module/plugin.

I'm willing to create a demo/fork for it, but I wouldn't want to waste
effort if it's something that wouldn't be accepted. If it's to be added at
all, it might be best to add it for 1.0, so as to reduce the amount of code
written without it in mind.


On Wed, Apr 3, 2013 at 6:44 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com
> wrote:

> Well, a full effect system might not be necessary "just" for safe plugins.
>
> Since we have a way in Rust to indicate which version a "plugin" we want
> to link to, we could apply some restrictions there.
>
> For example, specifying that only a certain list of other libraries can be
> used by this "plugin" (and typically none with IO features) and that it
> cannot use unsafe code would guarantee some sandboxing already. Similarly,
> the GC restriction could be placed there.
>
> -- Matthieu
>
>
> On Wed, Apr 3, 2013 at 5:26 PM, Dean Thompson <deansherthompson at gmail.com>wrote:
>
>> The Rust team refers to this as an "effect system".  They originally had
>> one, but that one proved unworkable and was deleted.  They continue to
>> regard it as desirable but difficult to get right, and as a potential
>> future.  Here's some history<http://irclog.gr/#search/irc.mozilla.org/rust/%22effect%20system%22>.
>> They would certainly welcome serious proposals or demos, although almost
>> certainly continuing to hold it out for post-1.0. They would think in terms
>> of first researching the most successful effect systems in other languages.
>>
>> Dean
>>
>> From: Grant Husbands <rust-dev at grant.x43.net>
>> Date: Wednesday, April 3, 2013 5:14 AM
>> To: <rust-dev at mozilla.org>
>> Subject: [rust-dev] Library Safety
>>
>> I've been following the Rust story with some interest and I'm excited
>> about the opportunities Rust brings for sandbox-free, secure system
>> software. However, there are some things that it lacks, that would
>> otherwise make it the obvious choice.
>>
>> One that I feel is important that has been touched upon by others is
>> having static assurances about code, especially imported libraries. If I
>> use a jpg library, I want to be sure that it isn't going to do be able to
>> do any unsafe operations, use GC or access the file-system or the network.
>> That way, I don't have to trust the code and can instead be assured that it
>> simply cannot perform any dangerous actions.
>>
>> Currently, to do that, I have to inspect the whole library. As a
>> developer without the time to do that, I'd much prefer for the import to be
>> annotated to indicate such things (or, ideally, to be annotated to indicate
>> the allowed dangers).
>>
>> This could be seen, of course, as a precursor to capabilities - reducing
>> ambient authority is a key first step in getting a capability-secure system
>> - but it's also a simple way of getting assurances about code without
>> having to inspect it.
>>
>> Does it seem like a reasonable thing to add? I may be able to find time
>> to work on it, should it be acceptable.
>>
>> Regards,
>> Grant Husbands.
>> _______________________________________________ Rust-dev mailing list
>> Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20130403/09e39569/attachment.html>


More information about the Rust-dev mailing list