Oyster Secret Storage Implementation #14
Conversation
vg-27
force-pushed
the
rajat/secret-store
branch
from
54d5f5d to
738a5e0
Compare
|
Impl looks, good, can add UTs and scripts for deployment. |
| wallets = signers.map((_, idx) => walletForIndex(idx)); | ||
|
|
||
| token = addrs[1], | ||
| noOfNodesToSelect = 3, |
| await expect(secretManager.acknowledgeStoreFailed(secretId)) | ||
| .to.be.revertedWithCustomError(secretManager, "SecretManagerAcknowledgedAlready"); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
add case where at least one secret store has acknowledged but not others.
| let secretId = 1; | ||
| await expect(secretManager.connect(signers[1]).terminateSecret(secretId)) | ||
| .to.be.revertedWithCustomError(secretManager, "SecretManagerNotUserStoreOwner"); | ||
| }); |
There was a problem hiding this comment.
few more cases:
- termination after termination
- termination after end timestamp
- combination of termination and acknowledgement time period
|
|
||
| //-------------------------------- TeeManager start ----------------------------------// | ||
|
|
||
| modifier onlySecretStore() { |
There was a problem hiding this comment.
Current approach is better as we already have the SECRET_STORE storage var. With onlyRole, we will have to do an extra transaction to grant the role.
There was a problem hiding this comment.
what's the pros of using onlyRole that we are missing here? Any security concerns? Also, you can set the ROLE during initialization of contract.
There was a problem hiding this comment.
TeeManager contract will be deployed first and then the Executors and SecretStore contracts. So, we cannot assign the role during initialization. I have made setter functions for these two contracts.
We can grant the roles within these setter functions but there isn't any security threat with the existing approach.
There was a problem hiding this comment.
Also, just in case we have to update the Executors or SecretStore contract, first we will have to revoke the role and then grant it to the new contract, so another overhead.
|
|
||
| //-------------------------------- TeeManager start ----------------------------------// | ||
|
|
||
| modifier onlySecretStore() { |
There was a problem hiding this comment.
what's the pros of using onlyRole that we are missing here? Any security concerns? Also, you can set the ROLE during initialization of contract.
| @@ -378,7 +378,9 @@ contract Executors is | |||
| uint256[] memory stakeAmounts = TEE_MANAGER.getTeeNodesStake(_enclaveAddresses); | |||
| uint256 len = _enclaveAddresses.length; | |||
| for (uint256 index = 0; index < len; index++) { | |||
| _insert_unchecked(_env, _enclaveAddresses[index], uint64(stakeAmounts[index] / STAKE_ADJUSTMENT_FACTOR)); | |||
| address enclaveAddress = _enclaveAddresses[index]; | |||
| if (executors[enclaveAddress].activeJobs < executors[enclaveAddress].jobCapacity) | |||
There was a problem hiding this comment.
make sure whoever is calling this method, doesn't put this check of active jobs, otherwise it would be redundant.
| @@ -21,8 +21,30 @@ contract JobsUser { | |||
|
|
|||
| event FailedCallback(uint256 indexed jobId, uint256 slashedAmount); | |||
|
|
|||
| // function createJob( | |||
There was a problem hiding this comment.
it is still being used in the serverless-v2 contracts, so let's keep it for now.
| address _enclaveAddress, | ||
| uint256 _storageOccupied | ||
| ) internal { | ||
| secretStores[_enclaveAddress].storageOccupied -= _storageOccupied; |
There was a problem hiding this comment.
we have to make sure storageOccupied get to the value zero before deregistration and remove stake. i.e. no secrets assigned.
There was a problem hiding this comment.
already being checked in the respective functions
Doc - https://docs.google.com/document/d/1DNkw2BPdrYesIp1z_q31amENeruZiuZSfchC7YXQr1w/edit#heading=h.kxzyz8ao5ap9