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

Remove all remnants of the OCap systems #45

Closed
5 tasks
hu55a1n1 opened this issue Apr 28, 2022 · 0 comments
Closed
5 tasks

Remove all remnants of the OCap systems #45

hu55a1n1 opened this issue Apr 28, 2022 · 0 comments
Assignees

Comments

@hu55a1n1
Copy link
Contributor

Summary

We currently have some vestigial OCap related code that is dysfunctional and should be removed from the ibc crate.

Problem Definition

Further to the excellent points raised by @plafer (https://github.com/informalsystems/ibc-rs/issues/2013#issuecomment-1090965987), and other related discussions (https://github.com/informalsystems/ibc-rs/issues/2013), I think we agree that it doesn't make sense to have an OCap facility in a system with untrusted modules and without strictly enforced memory isolation.
We currently use OCaps for two things - binding modules to ports and tracking channel/port ownership, so we need to figure out what exactly must be removed.

Note: this may be considered a divergence from the ICS spec.

Acceptance Criteria

Any unused OCap related code is removed from the ibc crate.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@plafer plafer self-assigned this May 3, 2022
@hu55a1n1 hu55a1n1 transferred this issue from informalsystems/hermes Sep 29, 2022
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

2 participants