get_secret authorizes using a caller-supplied address and then always reads from hard-coded @owner. However, set\_secret writes under the transaction signer. Anyone can create a Vault and set a secret which contradicts the documentation. Any signer can set up the secret but will not be able to retrieve it via the get\_secret function (presuming that this function is correctly implemented).
Only the specified owner address (in the .toml) should set and read their own secret. Currently, there is nothing preventing others from calling the set\_secret and setting up their own secrets.
Anybody can set their own secret without having the ability to directly checking it out. The documentation clearly specifies that only the specific owner address can set and retrieve the secret.
If the idea is to only have a specific owner setting the secret :
If the idea is to having anybody set up a secret and retrieve it then :
In Move for Aptos, the term "owner" refers to a signer, which is a verified account that owns a given resource, has permission to add resources and the ability to grant access or modify digital assets. Following this logic in this contest, the owner is the account that owns `Vault`. This means that anyone has right to call `set_secret` and then to own the `Vault` and to retrieve the secret from the `Vault` in `get_secret` function. Therefore, this group is invalid, because the expected behavior is anyone to call the `set_secret` function.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.