Skip to content
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

Limit imported interfaces for composed components #83

Merged
merged 2 commits into from
Aug 28, 2024

Conversation

scothis
Copy link
Contributor

@scothis scothis commented Aug 27, 2024

Components that are directly composed will never use any virtualized interface that it does not already import. Virtualizing additional interfaces limits the compatibility of the resulting component as it places an additional requirement on the host environment to satisfy each import, used or not.

We now inspect the composed component to match the interfaces it imports with the virtualized capabilities. If the composed component does not import the respective interface the resulting component will not virtualize that interface. In effect, use of --allow-all will behave as if the caller specifically approved the interfaces actually used.

The granularity of filtered imports is coarse. Interfaces that support a consumed capability may still appear as imports even if the composed component does not consume them explicitly.

Refs #82 (comment)

Components that are directly composed will never use any virtualized
interface that it does not already import. Virtualizing additional
interfaces limits the compatibility of the resulting component as it
places an additional requirement on the host environment to satisfy each
import, used or not.

We now inspect the composed component to match the interfaces it imports
with the virtualized capabilities. If the composed component does not
import the respective interface the resulting component will not
virtualize that interface. In effect, use of `--allow-all` will behave
as if the caller specifically approved the interfaces actually used.

The granularity of filtered imports is coarse. Interfaces that support
a consumed capability may still appear as imports even if the composed
component does not consume them explicitly.

Signed-off-by: Scott Andrews <scott@andrews.me>
@scothis
Copy link
Contributor Author

scothis commented Aug 27, 2024

@guybedford I had a couple false starts trying to make the filtering much more granular. As is, it follows the coarseness of the existing options. A more granular approach may still be useful, but this is simpler and resolves my concerns.

Copy link
Collaborator

@guybedford guybedford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, thank you for working on it. We should make sure to document the new API in the readme.

Just left some suggestions with regards to how we structure this, once we work through that it would be great to land.

src/lib.rs Show resolved Hide resolved
- move filtering to be a separate method from finalize
- perform composition in finalize when compose is requested
- update readme

Signed-off-by: Scott Andrews <scott@andrews.me>
@scothis scothis requested a review from guybedford August 28, 2024 18:15
@guybedford guybedford merged commit c451261 into bytecodealliance:main Aug 28, 2024
2 checks passed
@guybedford
Copy link
Collaborator

Looks great, thanks for adding this!

@scothis scothis deleted the import-filter branch August 28, 2024 18:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants