Open hats-bug-reporter[bot] opened 2 months ago
I forgot to add that this problem gets even worse since the humanity.owner
gets deleted upon bridging, this is especially problematic if users participated in the request by contributing for or against it.
delete humanity.owner;
The request would only be valid once it has been moved to the next phase. While it's still in a vouching phase, there is no problem to transfer the humanity. Note that if the renewal request is advanced while you are registered on the other chain, it should be challenged. See the registry rules.
About your second comment, it's too short to understand exactly what you mean, you may want to create a separate issue.
Github username: -- Twitter username: -- Submission hash (on-chain): 0xd9bd1f2c345fb79d1008a558830c3f51f369027d480c1031dc0a948979638a5b Severity: medium
Description: A user can create a request to renew his humanity by calling
renewHumanity
:The
requestCount
will be incremented by 1Now a user is still able to call
transferHumanity
because of the following reason:transferHumanity
will invokeccDischargeHumanity
for additional checks, one of which, is checking if there are any pending requests open by checkingThis will not fail since
renewHumanity
does not increment thenbPendingRequests
rather it uses a different system which is therequestCount
which is not checked here.This in itself breaks a core component of the contract as per:
* - Humanity must have no pending requests.
As a result, the following scenarios can occur:
renewHumanity
request with little to nomsg.value
.transferHumanity
.Additionally, others might deposit on his behalf and risk losing their funds if Bob decides to transfer. Either way, this situation will cause issues.
Fix
make sure to also check for the
requestCount
whenever transferring OR include thenbPendingRequests
incrementation insiderenewHumanity