cap-std
wasmer
cap-std | wasmer | |
---|---|---|
12 | 131 | |
621 | 17,786 | |
0.6% | 1.0% | |
6.6 | 9.9 | |
about 1 month ago | 7 days ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cap-std
-
Rust Library Team Aspirations | Inside Rust Blog
I believe you mean capability based, like cap-std.
-
A Performance Evaluation on Rust Asynchronous Frameworks
There might be another reason to prefer async-std right now: the Bytecode Alliance is working on a version of std with support for capability-based security (called cap-std: https://github.com/bytecodealliance/cap-std ), and their async version is based on async-std (called cap-async-std: https://github.com/bytecodealliance/cap-std/tree/main/cap-async-std ). Given the clout that the Bytecode Alliance has, async-std might end up carving a niche out in the Wasm domain.
-
Backdooring Rust crates for fun and profit
Would love to see something like this implemented around creating a Process in cap-std ( https://github.com/bytecodealliance/cap-std/issues/190 )
-
Scripting Languages of the Future
I think it's not discussed enough how things like language features shape how library APIs are formed. People usually seem to only consider the question "how would I use this feature?" and not "how would the standard library look like with this feature?", which is surprising given how much builtin libraries affect the pleasantness of a language.
One of the things I'm excited to see is the cap-std project for Rust [0] given what Pony [1] has demonstrated is possible with capabilities. I'm also hoping that languages like Koka [2] and OCaml [3] will demonstrate interesting use cases for algebraic effects.
[0] https://github.com/bytecodealliance/cap-std
[1] https://www.ponylang.io/discover
[2] https://koka-lang.github.io
[3] https://github.com/ocaml-multicore/effects-examples
- Is using crates more safe than using npm?
-
Why WebAssembly is innovative even outside the browser
I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level).
And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS.
But "sanboxing" some process running on a VM is completely independent of that!
WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes.
If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) when it isn't also capability-secure. Otherwise the model breaks.
To be capability-secure you have actually to rewrite the world…
¹ https://github.com/bytecodealliance/cap-std
-
Security review of "please", a sudo replacement written in Rust
The type system could definitely help. There's all sorts of things we can do. One really cool project is https://github.com/bytecodealliance/cap-std
- Preparing rustls for wider adoption
- cap-std: Capability-oriented version of the Rust standard library
-
First class I/O
On the topic of unsafe being used to describe raw file descriptors, on one hand, there is a sense in which file descriptors are pointers, into another memory. They can leak, dangle, alias, or be forged, in exactly the same way. On the other, there is an open issue about this.
wasmer
-
Bebop v3: a fast, modern replacement to Protocol Buffers
This is awesome. I'd love to have upstream support in Wasmer ( https://wasmer.io )
-
Unlocking the Power of WebAssembly
WebAssembly is extremely portable. WebAssembly runs on: all major web browsers, V8 runtimes like Node.js, and independent Wasm runtimes like Wasmtime, Lucet, and Wasmer.
-
Show HN: dockerc – Docker image to static executable "compiler"
Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...
As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.
[0]: https://github.com/ktock/container2wasm
[1]: https://wasmer.io/
- RustPython
-
Howto: WASM runtimes in Docker / Colima
I could not find any guide how to add WASM container capability to Docker running on Colima. This guide provides a few Colima templates for exactly this, which adds WasmEdge, Wasmtime and Wasmer runtime types.
-
Show HN: Mutable.ai – Turn your codebase into a Wiki
Just suggested as well Wasmer on Twitter! https://github.com/wasmerio/wasmer
Looking forward to seeing the results :)
- Jaq – A jq clone focused on correctness, speed, and simplicity
-
Prettier $20k Bounty was Claimed
The Biome team has been incredibly fast on solving the challenge and achieving 95% compatibility with Prettier [1]
Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon!
Keep up the great work!!
[1] https://github.com/biomejs/biome/issues/720
[2] https://wasmer.io/
[3] https://wasix.org/
-
The Curse of Docker
It's funny how WebAssembly can help overcome most of the issues mentioned on the blogpost (packaging, configuration, portability) if addressed properly.
That's the main reason Wasmer [1] was created :)
[1] https://wasmer.io
-
Bring garbage collected programming languages efficiently to WebAssembly
Thanks for the mention to Wasmer.
I'll put here a link in case is useful for future readers: https://wasmer.io/
What are some alternatives?
godot-wasm-engine
wasmtime - A fast and secure runtime for WebAssembly
watt - Runtime for executing procedural macros as WebAssembly
SSVM - WasmEdge is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. It powers serverless apps, embedded functions, microservices, smart contracts, and IoT devices.
cargo2nix - Granular builds of Rust projects for Nix
wasm3 - 🚀 A fast WebAssembly interpreter and the most universal WASM runtime
rusty-wacc-viewer
quickjs-emscripten - Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
cargo-supply-chain - Gather author, contributor and publisher data on crates in your dependency graph.
awesome-wasm-runtimes - A list of webassemby runtimes
effects-examples - Examples to illustrate the use of algebraic effects in Multicore OCaml
wasm-bindgen - Facilitating high-level interactions between Wasm modules and JavaScript