ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-01-31 00:24:13 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Make sure upload secret semantics are still supporting the security goals.

Browse Source
This commit is contained in:
Itamar Turner-Trauring 2022-01-20 10:56:08 -05:00
parent 1bf2b2ee5f
commit d5bac8e186
3 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/proposed/http-storage-node-protocol.rst
View File

@ -493,7 +493,8 @@ Handling repeat calls:
* If the same API call is repeated with the same upload secret, the response is the same and no change is made to server state.
This is necessary to ensure retries work in the face of lost responses from the server.
* If the API calls is with a different upload secret, this implies a new client, perhaps because the old client died.
In this case, all relevant in-progress uploads are canceled, and then the command is handled as usual.
In order to prevent storage servers from being able to mess with each other, this API call will fail, because the secret doesn't match.
The use case of restarting upload from scratch if the client dies can be implemented by having the client persist the upload secret.
Discussion
``````````

4
src/allmydata/storage/http_server.py
View File

@ -187,9 +187,7 @@ class HTTPServer(object):
# TODO add BucketWriters only for new shares
pass
else:
# New session.
# TODO cancel all existing BucketWriters, then do
# self._storage_server.allocate_buckets() with given inputs.
# TODO Fail, since the secret doesnt match.
pass
else:
# New upload.

9
src/allmydata/test/test_storage_http.py
View File

@ -361,16 +361,15 @@ class ImmutableHTTPAPITests(AsyncTestCase):
TBD in https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3860
"""
def test_bucket_allocation_new_upload_key(self):
def test_bucket_allocation_new_upload_secret(self):
"""
If a bucket was allocated with one upload key, and a different upload
key is used to allocate the bucket again, the previous download is
cancelled.
If a bucket was allocated with one upload secret, and a different upload
key is used to allocate the bucket again, the second allocation fails.
TBD in https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3860
"""
def test_upload_with_wrong_upload_key_fails(self):
def test_upload_with_wrong_upload_secret_fails(self):
"""
Uploading with a key that doesn't match the one used to allocate the
bucket will fail.