-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Context-Based Security #58
Comments
Shouldn't that context be added to all functions, maybe as the first parameter? |
@jedisct1 No. You can chain them. For example: |
Got it. And if the root context is read-only, lock contention shouldn't be an issue. How do applications get that root context? Should some kind of |
The handle is a preopen. No |
But how do libraries get that handle? Is it by looking for a specific path such as |
@sunfishcode is working on this currently. Thoughts? |
@jedisct1 Generally, I would expect them to expect the crypto policy as input. |
Yes, it sounds like this is a handle that the program should declare as an input argument, though the specific mechanisms for doing this aren't implemented yet. |
There are a number of functions which take no context as input. I think I have caught all of them:
options_open
secrets_manager_open
keypair_generate
keypair_import
publickey_import
secretkey_import
signature_import
symmetric_key_generate
symmetric_key_import
symmetric_state_open
These functions do not align with the general strategy of context-based security as used in other WASI specifications. All WASI functions should have some context object (i.e. handle) which is either provided by the runtime or derived from a handle provided by the runtime.
One suggestion for this handle might be a
policy
handle which allows the runtime to define which algorithms are permitted.The text was updated successfully, but these errors were encountered: