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 <[email protected] > 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 > <[email protected]>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 <[email protected]> >> Date: Wednesday, April 3, 2013 5:14 AM >> To: <[email protected]> >> 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 >> [email protected] https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
