Wasmtime GitHub notifications bot (Aug 30 2023 at 20:34): Wasmtime GitHub notifications bot (Aug 30 2023 at 20:34):jameysharp commented on issue #6808:
This looks like a rebase that went wrong and is pulling in commits from other branches. I think only 0b024af was supposed to be in this PR, and GitHub automatically tagging in Cranelift folks is a false positive as a result. So I'm removing the review request for Chris.
Wasmtime GitHub notifications bot (Aug 30 2023 at 21:44):github-actions[bot] commented on issue #6808:
Subscribe to Label Action
cc @cfallin, @fitzgen, @peterhuene
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:meta", "cranelift:module", "cranelift:wasm", "isle", "wasmtime:c-api", "wasmtime:docs"Thus the following users have been cc'd because of the following labels:
- cfallin: isle
- fitzgen: isle
- peterhuene: wasmtime:c-api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Aug 31 2023 at 05:28):veeshi commented on issue #6808:
I rebased on the 12.0 release branch so we can use this in our platform. I can see in the 13.0 pre-release wasi-http has a
WasiHttptrait so this PR will no longer be needed.
Wasmtime GitHub notifications bot (Aug 31 2023 at 15:54):jameysharp commented on issue #6808:
I'm not particularly familiar with the status of wasi-http, but it sounds to me like you don't expect to merge this PR because we have a different solution that will meet your needs. In that case, can we close this PR?
Wasmtime GitHub notifications bot (Aug 31 2023 at 16:28):pchickey commented on issue #6808:
Sorry I didn't chime in earlier. We have had various wasi-http implementation plans we would get to "real soon now" for a while now.
The short version is: I don't believe that we should implement ACLs as a host functionality in any of our component interfaces, including HTTP. Instead, we want to see ACLs implemented as a component which attenuates component interfaces.
Over in the wasi-virt project, Guy has been demonstrating some of the patterns possible for component composition which interpose between the host and the user's component. In that project, he is demonstrating providing extra environment variables, a read-only filesystem image, and other basic on/off functionality for wasi interfaces.
I think the best design for an http ACL is a component generator like wasi-virt that, given an ACL, generates a component that exports a wasi-http interface to the user's component, and imports a wasi-http implementation. When wiring that export to that import, the ACL component will make any access control checks and accept (by forwarding) or reject (by returning an error) the user's import calls.
This has a bunch of advantages over building it into the host: 1. it works on any component runtime, not just wasmtime, 2. it minimizes the amount of code we need to trust in the host. practically this shows up when we
cargo vetour dependencies, but that only covers safety and not correctness. 3. users (embedders) get to pick and choose whatever ACL implementation they like. For instance, https://github.com/bytecodealliance/wasmtime/pull/6401 is a similar, but different, implementation of this same sort of ACL. Which one is better? I personally don't know, but the person embedding wasmtime to provide some service is in a better position to know, so I want the decision be as late-binding as possible. I'd like the embedder to choose whatever attenuators that are appropriate for their needs,wasm-composethem with their user's component, and load them into wasmtime.
Wasmtime GitHub notifications bot (Aug 31 2023 at 22:05):veeshi commented on issue #6808:
I'm not particularly familiar with the status of wasi-http, but it sounds to me like you don't expect to merge this PR because we have a different solution that will meet your needs. In that case, can we close this PR?
Yep this PR can be closed. It was more of a proof of concept to highlight one possible solution to this problem and to give us something to work with in our platform.
I think the best design for an http ACL is a component generator like wasi-virt that, given an ACL, generates a component that exports a wasi-http interface to the user's component, and imports a wasi-http implementation. When wiring that export to that import, the ACL component will make any access control checks and accept (by forwarding) or reject (by returning an error) the user's import calls.
I wasn't aware of wasi-virt till now but it is a better approach and one which gives flexibility to end users.
Wasmtime GitHub notifications bot (Aug 31 2023 at 22:17):pchickey commented on issue #6808:
Thanks. Please stay in touch with what your platform needs from wasmtime, whether here or on the bytecode alliance discord.
Last updated: Oct 23 2024 at 20:03 UTC