New setting: API/Repo Trust level
- Dominant language
- Go
- Stars
- 17.1k
- Forks
- 3.2k
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 11
Description
Currently we do not verify blocks read from local storage. There is a setting for that, but it defaults to off (#1152). If blocks need to be verified really depends on the level of trust of the disk storage.
There are some similar issues with the pending filestore (#2634) code. For example it is currently possible to add files with the server online. This works by sending both the absolute path of file and the contents. The server will then open the file on its end and verify that the contents are the same as is being sent by the client. This seams secure, but unless blocks are always verified there is a small attack vector. That if the file than changes someone could possible see the contents of the new file. This can only be exploited by someone with access to the API server as they will need to know hash XYZ originally corresponded to the contents of file ZZZ.
Both of these depends on the trust we have with the API/Repo. I therefore propose a new setting, lets call it RepoAPITrust, that has three values 'Low' (assume nothing, always check blocks), 'Medium' (assume the repo storage and API are reasonable secure), High (assume the repo storage and API are highly secure). The default will be 'Low'. For more performance users can be advised to set this to 'Medium'. Using the 'High' setting will be discouraged unless the user really knows what they are doing.
For obvious security reasons this setting should only be allowed to be changed locally. Maybe even by forcing a user to edit a file. In addition this setting will independent of normal settings such as `HashOnRead`. However, for example, `HashOnRead` will not be allowed to to False unless the trust level is `Medium` of Higher.
Thoughts? If there are not any strong objections I am likely to try to implement something soon to avoid possible security problems with the filestore (#2634) code.
Contributor guide
Assessment
This issue has not been assessed yet.