Impact: High
Likelihood: Low
According to the discussion with the team, it is expected that in Space
contracts, only one Role can have the Permissions.Owner permission.
Currently, multiple Roles can be created containing this permission.
This is caused by Space.sol’s createRole() function allowing the
OpenZeppelin owner to create new owner-permissioned roles without limit.
Remediations to consider:
Do not allow multiple roles to be created with the ownership permission.
This could be done with something like: if Space.sol’s ownerRoleId is
set, do not allow new roles to be created with the Permissions.Owner
permission.
Fixes HNT-703 as well
Removing the OpenZeppelin ownership logic, and, checking directly for
the ownership of the Space’s SpaceOwner NFT. The SpaceFactory could be
the owner during the bootstrapping phase, and afterwards, could transfer
the NFT to the proper owner. Doing a direct check like
_spaceOwner().ownerOf(tokenId) == _msgSender() would be safe because
that’s what the owner entitlement is going to check eventually.
---------
Co-authored-by: Kerem Kazan <kerem.kazan@gmail.com>
this pr computes dendrite docker version from the commit hash, instead
of bumping versions. the previous setup caused issues and conflicts when
branch protection is enabled. this way we can seamlessly keep pushing to
main and it will keep getting built and published
Overloaded isEntitled func in ISpace.sol and Space.sol caused the generated client types to turn into string names. Renaming one of them to isEntitledToChannel.
- Add new functions to modify role name, permissions, token entitlement
and user entitlement with a single call
- Add new solidity tests for the new functions
- Re-generated TypeScript and Go types for both localhost and goerli
- Created a package.json in servers/dendrite. Moving forward, this file
is our canonical dendrite version, and our docker builds will depend on
this version.
- Created a script that extracts the package.json version and puts it
into the GitHub actions build environment as `RELEASE_VERSION`.
- Updated the GitHub action so that it builds and publishes the docker
image to dockerhub whenever we merge dendrite changes to main.
Co-authored-by: Automated Version Bump <gh-action-bump-version@users.noreply.github.com>
Issue: matrix room id does not always resolve to spaceId or channelId
correctly.
Root cause: The clientApi routing endpoint and the syncapi routing
endpoint uses different stores to query for the current room states.
One is correct, the other has incomplete events. Fix the issue by using
the correct store in both routing code paths.
- space manager catches error when adding roleId to channels so that
client can get meaningful error
- Update the createChannel tests to expect the new error AddRoleFailed
- Re-generate localhost and goerli types
- Update the start-local-dendrite.sh to be able to start local dendrite
with / without authorization checks
- Update dendrite config to support command line arg
Closes HNT-244.
The following PR implements Space,Channel soft deletion using on-chain
`disabled` flag scope to space, channel respectively. On message sync,
dendrite will now gate disabled rooms by performing a leave on the user
attempting to sync unless the user is the owner (more on this later). To
re-join, given rooms (spaces,channels) are created by default using
`invite` membership state, the owner will need to undo the on-chain
`disabled` flag, setting it false then re-invite users that left the
room as a side effect of it becoming disabled previously.
The owner does not leave the space, channel because if they did then
there would be no one left to invite users let alone themselves back in
if the action is ever undone.
What is not implemented in this PR:
1. **Transitive leaves on channels in a space** - If a space is
disabled, users will leave the space but not the channels within the
space. To allow for fully disabling a space and all its' channels, the
client can offer a view to the owner that iterates over the channels and
space to disable all on-chain. Furthermore, we could implement a batch
on-chain method that fully disables all channels within a space (plus
the space) in one on-chain call to save the owner gas.
2. **Data deletion** - No data is remove from the DAGs or on-chain.
Therefore deletion is soft and reversible.
3. **New hook to check if a room is disabled** - the client can leverage
existing on-chain public read only methods `getSpaceInfoBySpaceId`,
`getChannelInfoByChannelId` to read the state of each in order to remove
spaces, channels from a member's view that are disabled.
Need the address to implement the ZionRoleManagerShim
I ran this in zion-governance/ and it worked :
forge script scripts/Local.s.sol:DeployLocal --rpc-url
http://localhost:8545/ --private-key … --broadcast
space-manager.json has the rolemanager address
