mitigate these risks.
What we mean by "security" is something different. *The service provider
-never has the ability to read or modify your data in the first place—never.*
+never has the ability to read or modify your data in the first place: never.*
If you use Tahoe-LAFS, then all of the threats described above are non-issues
to you. Not only is it easy and inexpensive for the service provider to
maintain the security of your data, but in fact they couldn't violate its
doesn't require you to perform a manual pre-encryption step or cumbersome key
management. (After all, having to do cumbersome manual operations when
storing or accessing your data would nullify one of the primary benefits of
-using cloud storage in the first place—convenience.)
+using cloud storage in the first place: convenience.)
Here's how it works:
The core Tahoe developers promise never to change Tahoe-LAFS to facilitate
government access to data stored or transmitted by it. Even if it were
-desirable to facilitate such access—which it is not—we believe it would not
-be technically feasible to do so without severely compromising Tahoe-LAFS'
-security against other attackers. There have been many examples in which
-backdoors intended for use by government have introduced vulnerabilities
-exploitable by other parties (a notable example being the Greek cellphone
-eavesdropping scandal in 2004/5). RFCs `1984`_ and `2804`_ elaborate on the
-security case against such backdoors.
+desirable to facilitate such access -- which it is not -- we believe it would
+not be technically feasible to do so without severely compromising
+Tahoe-LAFS' security against other attackers. There have been many examples
+in which backdoors intended for use by government have introduced
+vulnerabilities exploitable by other parties (a notable example being the
+Greek cellphone eavesdropping scandal in 2004/5). RFCs `1984`_ and `2804`_
+elaborate on the security case against such backdoors.
.. _1984: https://tools.ietf.org/html/rfc1984
.. _2804: https://tools.ietf.org/html/rfc2804
dir>/private/convergence) and re-used after that. So the same file content
uploaded from the same client will always have the same cap. Uploading the
file from a different client with a different convergence secret would result
-in a different cap—and in a second copy of the file's contents stored on the
-grid. If you want files you upload to converge (also known as "deduplicate")
-with files uploaded by someone else, just make sure you're using the same
-convergence secret when you upload files as they
+in a different cap -- and in a second copy of the file's contents stored on
+the grid. If you want files you upload to converge (also known as
+"deduplicate") with files uploaded by someone else, just make sure you're
+using the same convergence secret when you upload files as they
The advantages of deduplication should be clear, but keep in mind that the
convergence secret was created to protect confidentiality. There are two
like Twisted, Foolscap, pycryptopp, and zfec. "``tahoe --version-and-path``"
will also show the path from which each library was imported.
-On Unix systems, the shell expands filename wildcards — ``'*'`` and ``'?'`` —
-before the program is able to read them, which may produce unexpected
-results for many ``tahoe`` comands. We recommend, if you use wildcards,
-to start the path with "``./``", for example "``tahoe cp -r ./* somewhere:``".
-This prevents the expanded filename from being interpreted as an option
-or as an alias, allowing filenames that start with a dash or contain
-colons to be handled correctly.
+On Unix systems, the shell expands filename wildcards (``'*'`` and ``'?'``)
+before the program is able to read them, which may produce unexpected results
+for many ``tahoe`` comands. We recommend, if you use wildcards, to start the
+path with "``./``", for example "``tahoe cp -r ./* somewhere:``". This
+prevents the expanded filename from being interpreted as an option or as an
+alias, allowing filenames that start with a dash or contain colons to be
+handled correctly.
On Windows, a single letter followed by a colon is treated as a drive
specification rather than an alias (and is invalid unless a local path is
This instructs the node to move a child of the given source directory, into
a different directory and/or to a different name. The command is named
``relink`` because what it does is add a new link to the child from the new
- location, then remove the old link. Nothing is actually "moved" — the child
+ location, then remove the old link. Nothing is actually "moved": the child
is still reachable through any path from which it was formerly reachable,
and the storage space occupied by its ciphertext is not affected.
A person could learn the storage index of a file in several ways:
-1. By being granted the authority to read the immutable file—i.e. by being
+1. By being granted the authority to read the immutable file: i.e. by being
granted a read capability to the file. They can determine the file's
storage index from its read capability.
longer vulnerable to this problem.
Note that the issue is local to each storage server independently of other
-storage servers—when you upgrade a storage server then that particular
+storage servers: when you upgrade a storage server then that particular
storage server can no longer be tricked into deleting its shares of the
target file.
If you can't immediately upgrade your storage server to a version of
Tahoe-LAFS that eliminates this vulnerability, then you could temporarily
shut down your storage server. This would of course negatively impact
-availability—clients would not be able to upload or download shares to that
-particular storage server while it was shut down—but it would protect the
-shares already stored on that server from being deleted as long as the server
-is shut down.
+availability -- clients would not be able to upload or download shares to
+that particular storage server while it was shut down -- but it would protect
+the shares already stored on that server from being deleted as long as the
+server is shut down.
If the servers that store shares of your file are running a version of
Tahoe-LAFS with this vulnerability, then you should think about whether
disk, memory, cloud storage, and API usage.
-Network usage—bandwidth and number-of-round-trips
--------------------------------------------------
+Network usage: bandwidth and number-of-round-trips
+--------------------------------------------------
When a Tahoe-LAFS storage client allocates a new share on a storage server,
the backend will request a list of the existing cloud objects with the
============
This design worsens a known “write hole” issue in Tahoe-LAFS when updating
-the contents of mutable files. An update to a mutable file can require changing
-the contents of multiple chunks, and if the client fails or is disconnected
-during the operation the resulting state of the stored cloud objects may be
-inconsistent—no longer containing all of the old version, but not yet containing
-all of the new version. A mutable share can be left in an inconsistent state
-even by the existing Tahoe-LAFS disk backend if it fails during a write, but
-that has a smaller chance of occurrence because the current client behavior
-leads to mutable shares being written to disk in a single system call.
+the contents of mutable files. An update to a mutable file can require
+changing the contents of multiple chunks, and if the client fails or is
+disconnected during the operation the resulting state of the stored cloud
+objects may be inconsistent: no longer containing all of the old version, but
+not yet containing all of the new version. A mutable share can be left in an
+inconsistent state even by the existing Tahoe-LAFS disk backend if it fails
+during a write, but that has a smaller chance of occurrence because the
+current client behavior leads to mutable shares being written to disk in a
+single system call.
The best fix for this issue probably requires changing the Tahoe-LAFS storage
protocol, perhaps by extending it to use a two-phase or three-phase commit
projects / tahoe-lafs / tahoe-lafs.git / commitdiff