It sounds to me like
you're talking about something similar to the current lint modes for GC
etc?
Niko
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.
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 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. 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
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. 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.
|
