Skip to content

Separate dylink and encasementlib cleanly #189

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

Open
aaaaalbert opened this issue Sep 7, 2016 · 0 comments
Open

Separate dylink and encasementlib cleanly #189

aaaaalbert opened this issue Sep 7, 2016 · 0 comments

Comments

@aaaaalbert
Copy link
Contributor

dylink.r2py is RepyV2's functional replacement for Python's import statement and lets Repy code import libraries at runtime. encasementlib.r2py provides means for security layers to override, extend or limit the API that is exposed to sandboxed code. Both modules perform important tasks, but their current implementation does not assign features distinctly (so that e.g. dylink offers its own dispatch call).

We should document the required and desired behavior for both modules, and then sort out where and how to best draw the line, and also how to ensure that the features are compatible. For instance, dylink should behave identical to Python's import whenever possible, but pre- and post-seclayer dy_imports must be separated and not refer to cached modules, just like encasementlib separates the last sandbox from every preceding sandbox.

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

No branches or pull requests

1 participant