There's a discussion on the Rust discussion board about the recent NPM issue in which somebody upgraded a widely used module to contain an attack.
There's lots of talk about sandboxes, so I introduced the idea of ocaps. The objection is the amount of work that must be done to convert enough of the ecosystem.I know Adrian Mettler implemented Joe-E for his Ph.D. thesis; Marc Stiegler did something similar for OCaml; and Mark Miller and others are dragging the EcmaScript committee kicking and screaming in that direction. So, how hard it is? What's the least amount that needs to be converted to have a useful system?
[dependencies]bar = { version = "1.2.3", allow_unsafe = ["foo/fire_the_missiles"] }
[dependencies]baz = { version = "0.1.2", allow_unsafe = ["bar/foo/fire_the_missiles"] }
I of course did the entire OCaml ocap system, including taming of the libraries, in 2 weeks over the Christmas holidays. Unsurprisingly, OCaml's library was both well designed for modularity and was also small. No UI. I disallowed using the Marshalling module which was all about zapping bits using pointers. I tamed the file system and the tcp/ip, sockets, etc. networking modules. Can't remember what else there was, but I tamed everything in the standard OCaml library. Java was of course another matter entirely. Months, probably 6. Of course that was the first taming effort ever by anyone, but I don't think that was really a big part of the problem, it was mainly the boundless vastness of Java's libraries. by and large the Java libraries were also well modularized, though you could tell that certain libraries were written by idiots, like the library implementing the global mutable keyboard. I later looked at the C# library, another enormous collection of stuff, and much less well designed than the Java libraries, it would probably take a man-year.Rust had Brendan involved. Hard to believe it isn't well designed, and probably the core lib is small. So it could be 2 weeks to do it as well, like OCaml.Converting code that already uses the untamed stuff is of course an entirely different matter. Completely indeterminable from here. the important lesson from both OCaml and Java is that, for the typical programmer doing typical things, the changes in what he needs to do to work with a tamed library are surprisingly limited. The difficulty in upgrading the programmers will surely be greater than the difficulty in upgrading the libraries, but not because there is either too much to learn or too great a change, it's just that programmers, like other humans, hate having to learn anything different. Of course, rust is young enough, maybe it's still early adopters who don't mind learning a new trick.And of course the other thing we proved with OCaml is, there doesn't have to be a performance hit. Emily, the ocap version, generated executables that were, for many applications, just as fast as raw OCaml. Not surprising in retrospect: the things you care most about taming are the things involving i/o, which are already so slow a little indirection in the code is quite invisible.--marcs
----
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.
[...]
For Rust, I think the place to start is taming "unsafe".
Crates that do not rely on the standard library tend to work well with WebAssembly.
Really? That seems like the lowest bang-for-the buck that I can see.
There's already a [forbid(unsafe_code)] mechanism
and a reasonably strong sense in the community that it's a best practice (and tools such as https://crates.io/crates/cargo-geiger).
If people are interested, one such discussion on (some form of) capabilities in Rust is now going on here.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/06b327ba-934e-4952-81b6-a7e704a77f11%40googlegroups.com.
Also some talk about capability based apis in Rust
There's now also a parallel discussion, here (started by myself and definitely not my most diplomatic work). I'd prefer full ocaps, but I'm only arguing for compile-time restriction of imports, there.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/0e1c3d9a-05b5-463d-8f13-7063519e4ef6%40googlegroups.com.