You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A KPASS may include a list of revokers. Each of the revokers is given a weight and the pass itself has a revokeThreshold. If addresses with sufficient weight cast a revokeFriend() vote, the KPASS will be voided and the validators will not accept such a pass and KimlikDAO nodes will stop persisting its contents.
To be more specific, the user sets a revokeThreshold and assigns some weights to addresses of their choosing. Each time an address call the revokeFriend() method of the KPASS, the revokeThreshold of the KPASS will be decremented by the weight of the caller.
If the revokeThreshold becomes 0 or smaller, the KPASS will be invalidated.
We do not allow incrementing the revokeThreshold after the creation of the pass. This is because if a KPASS is stolen (i.e., the holder gets their wallet private keys stolen) the attacker should not be able to disable to social revoke functionality. If they can increment the revoke threshold arbitrarily, they can effectively disable the social revoke functionality.
In ab914f3, we introduced a public setRevokers() method, which should not give the attacker for a way to disable social revoke.
Think of attack vectors and write tests to ensure that the social revoke cannot be disabled even if the wallet private keys are stolen.
The tests may go into tests/KimlikDAOPassRevokeTest.sol.
The text was updated successfully, but these errors were encountered:
A KPASS may include a list of revokers. Each of the revokers is given a weight and the pass itself has a
revokeThreshold
. If addresses with sufficient weight cast arevokeFriend()
vote, the KPASS will be voided and the validators will not accept such a pass and KimlikDAO nodes will stop persisting its contents.To be more specific, the user sets a
revokeThreshold
and assigns some weights to addresses of their choosing. Each time an address call therevokeFriend()
method of the KPASS, therevokeThreshold
of the KPASS will be decremented by the weight of the caller.If the revokeThreshold becomes 0 or smaller, the KPASS will be invalidated.
We do not allow incrementing the
revokeThreshold
after the creation of the pass. This is because if a KPASS is stolen (i.e., the holder gets their wallet private keys stolen) the attacker should not be able to disable to social revoke functionality. If they can increment the revoke threshold arbitrarily, they can effectively disable the social revoke functionality.In ab914f3, we introduced a public
setRevokers()
method, which should not give the attacker for a way to disable social revoke.Think of attack vectors and write tests to ensure that the social revoke cannot be disabled even if the wallet private keys are stolen.
The tests may go into
tests/KimlikDAOPassRevokeTest.sol
.The text was updated successfully, but these errors were encountered: