tahoe-lafs/trac-2024-07-25

helper: client should check up on the helper's work #724

New issue

Open

opened 2009-05-31 19:51:48 +00:00 by warner · 0 comments

warner commented

2009-05-31 19:51:48 +00:00

Owner

Really, a client which uploads a file through the Helper should turn around immediately afterwards and verify that the helper really did it's job. The most intensive approach would be to perform a full verifier run (download all shares and check all bits). A more appropriate choice might be to perform a file check plus download the UEB from all shares to make sure it matches the value returned by the helper.

Once #722 and #723 are fixed, a change like this would merely be a reliability improvement: if the helper is buggy or malicious (or not connected to the complete/correct serverlist), this would allow the client to detect it right away, while the original file is still available.

The client would respond to a helper failure by performing a direct (helperless) upload, which is obviously slower but then removes reliance upon the helper for reliability/availability.

Really, a client which uploads a file through the Helper should turn around immediately afterwards and verify that the helper really did it's job. The most intensive approach would be to perform a full verifier run (download all shares and check all bits). A more appropriate choice might be to perform a file check plus download the UEB from all shares to make sure it matches the value returned by the helper. Once #722 and #723 are fixed, a change like this would merely be a reliability improvement: if the helper is buggy or malicious (or not connected to the complete/correct serverlist), this would allow the client to detect it right away, while the original file is still available. The client would respond to a helper failure by performing a direct (helperless) upload, which is obviously slower but then removes reliance upon the helper for reliability/availability.

tahoe-lafs added the

labels 2009-05-31 19:51:48 +00:00

tahoe-lafs added this to the undecided milestone 2009-05-31 19:51:48 +00:00

Sign in to join this conversation.

No labels

LeastAuthority.com automation

cannot reproduce

code-frontend-cli

code-frontend-ftp-sftp

code-frontend-magic-folder

code-frontend-web

code-peerselection

dev-infrastructure

somebody else's problem

was already fixed

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#724

No description provided.