http://tahoe-lafs.org/source/tahoe/trunk/docs/known_issues.rst
+== issues in Tahoe v1.8.2, released 30-Jan-2011 ==
+
+Unauthorized deletion of an immutable file by its storage index
+---------------------------------------------------------------
+
+Due to a flaw in the Tahoe-LAFS storage server software in v1.3.0 through
+v1.8.2, a person who knows the "storage index" that identifies an immutable
+file can cause the server to delete its shares of that file.
+
+If an attacker can cause enough shares to be deleted from enough storage
+servers, this deletes the file.
+
+This vulnerability does not enable anyone to read file contents without
+authorization (confidentiality), nor to change the contents of a file
+(integrity).
+
+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
+ granted a read capability to the file. They can determine the file's
+ storage index from its read capability.
+
+2. By being granted a verify capability to the file. They can determine the
+ file's storage index from its verify capability. This case probably
+ doesn't happen often because users typically don't share verify caps.
+
+3. By operating a storage server, and receiving a request from a client that
+ has a read cap or a verify cap. If the client attempts to upload,
+ download, or verify the file with their storage server, even if it doesn't
+ actually have the file, then they can learn the storage index of the file.
+
+4. By gaining read access to an existing storage server's local filesystem,
+ and inspecting the directory structure that it stores its shares in. They
+ can thus learn the storage indexes of all files that the server is holding
+ at least one share of. Normally only the operator of an existing storage
+ server would be able to inspect its local filesystem, so this requires
+ either being such an operator of an existing storage server, or somehow
+ gaining the ability to inspect the local filesystem of an existing storage
+ server.
+
+*how to manage it*
+
+Tahoe-LAFS version v1.8.3 or newer (except v1.9a1) no longer has this flaw;
+if you upgrade a storage server to a fixed release then that server is no
+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 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.
+
+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
+someone can learn the storage indexes of your files by one of the methods
+described above. A person can not exploit this vulnerability unless they have
+received a read cap or verify cap, or they control a storage server that has
+been queried about this file by a client that has a read cap or a verify cap.
+
+Tahoe-LAFS does not currently have a mechanism to limit which storage servers
+can connect to your grid, but it does have a way to see which storage servers
+have been connected to the grid. The Introducer's front page in the Web User
+Interface has a list of all storage servers that the Introducer has ever seen
+and the first time and the most recent time that it saw them. Each Tahoe-LAFS
+gateway maintains a similar list on its front page in its Web User Interface,
+showing all of the storage servers that it learned about from the Introducer,
+when it first connected to that storage server, and when it most recently
+connected to that storage server. These lists are stored in memory and are
+reset to empty when the process is restarted.
+
+See ticket `#1528`_ for technical details.
+
+.. _#1528: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
+
+
== issues in Tahoe v1.1.0, released 2008-06-11 ==
.. _the "historical known issues" document: historical/historical_known_issues.txt
-Issues in Tahoe-LAFS v1.8.2, released 2011-01-30
+Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
- * `Unauthorized deletion of an immutable file by its storage index`_
* `Potential unauthorized access by JavaScript in unrelated files`_
* `Potential disclosure of file through embedded hyperlinks or JavaScript in that file`_
* `Command-line arguments are leaked to other local users`_
* `Known issues in the FTP and SFTP frontends`_
* `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
-----
-
-Unauthorized deletion of an immutable file by its storage index
----------------------------------------------------------------
-
-Due to a flaw in the Tahoe-LAFS storage server software in v1.3.0 through
-v1.8.2, a person who knows the "storage index" that identifies an immutable
-file can cause the server to delete its shares of that file.
-
-If an attacker can cause enough shares to be deleted from enough storage
-servers, this deletes the file.
-
-This vulnerability does not enable anyone to read file contents without
-authorization (confidentiality), nor to change the contents of a file
-(integrity).
-
-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
- granted a read capability to the file. They can determine the file's
- storage index from its read capability.
-
-2. By being granted a verify capability to the file. They can determine the
- file's storage index from its verify capability. This case probably
- doesn't happen often because users typically don't share verify caps.
-
-3. By operating a storage server, and receiving a request from a client that
- has a read cap or a verify cap. If the client attempts to upload,
- download, or verify the file with their storage server, even if it doesn't
- actually have the file, then they can learn the storage index of the file.
-
-4. By gaining read access to an existing storage server's local filesystem,
- and inspecting the directory structure that it stores its shares in. They
- can thus learn the storage indexes of all files that the server is holding
- at least one share of. Normally only the operator of an existing storage
- server would be able to inspect its local filesystem, so this requires
- either being such an operator of an existing storage server, or somehow
- gaining the ability to inspect the local filesystem of an existing storage
- server.
-
-*how to manage it*
-
-Tahoe-LAFS version v1.8.3 or newer (except v1.9a1) no longer has this flaw;
-if you upgrade a storage server to a fixed release then that server is no
-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 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.
-
-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
-someone can learn the storage indexes of your files by one of the methods
-described above. A person can not exploit this vulnerability unless they have
-received a read cap or verify cap, or they control a storage server that has
-been queried about this file by a client that has a read cap or a verify cap.
-
-Tahoe-LAFS does not currently have a mechanism to limit which storage servers
-can connect to your grid, but it does have a way to see which storage servers
-have been connected to the grid. The Introducer's front page in the Web User
-Interface has a list of all storage servers that the Introducer has ever seen
-and the first time and the most recent time that it saw them. Each Tahoe-LAFS
-gateway maintains a similar list on its front page in its Web User Interface,
-showing all of the storage servers that it learned about from the Introducer,
-when it first connected to that storage server, and when it most recently
-connected to that storage server. These lists are stored in memory and are
-reset to empty when the process is restarted.
-
-See ticket `#1528`_ for technical details.
-
-.. _#1528: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1528
-
-
----
Potential unauthorized access by JavaScript in unrelated files
-ANNOUNCING Tahoe, the Least-Authority File System, v1.8.3
+ANNOUNCING Tahoe, the Least-Authority File System, v1.9.0
The Tahoe-LAFS team is pleased to announce the immediate
-availability of version 1.8.3 of Tahoe-LAFS, an extremely
+availability of version 1.9.0 of Tahoe-LAFS, an extremely
reliable distributed storage system. Get it here:
-https://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.rst
+https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst
Tahoe-LAFS is the first distributed storage system to offer
"provider-independent security" — meaning that not even the
without your consent. Here is the one-page explanation of its
unique security and fault-tolerance properties:
-https://tahoe-lafs.org/source/tahoe/trunk/docs/about.rst
+https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst
-The previous stable release of Tahoe-LAFS was v1.8.2, which was
-released January 30, 2011 [1].
+The previous stable release of Tahoe-LAFS was v1.8.3, which was
+released September 13, 2011 [1].
-v1.8.3 is a stable bugfix release which fixes a security issue. See the file
-[2] and known_issues.rst [3] file for details.
+v1.9.0 offers new features. See the NEWS file [2] and known_issues.rst [3]
+file for details.
WHAT IS IT GOOD FOR?
clients of all versions back to v1.0 and clients from this
release can use servers of all versions back to v1.0.
-This is the fourteenth release in the version 1 series. This
+This is the fifteenth release in the version 1 series. This
series of Tahoe-LAFS will be actively supported and maintained
for the foreseeable future, and future versions of Tahoe-LAFS
will retain the ability to read and write files compatible
SPONSORSHIP
-Atlas Networks has contributed several hosted servers for performance
-testing. Thank you to Atlas Networks for their generous and public-spirited
-support.
+Atlas Networks has contributed several hosted servers for
+performance testing. Thank you to Atlas Networks for their
+generous and public-spirited support.
HACK TAHOE-LAFS!
ACKNOWLEDGEMENTS
-This is the eighth release of Tahoe-LAFS to be created solely
+This is the ninth release of Tahoe-LAFS to be created solely
as a labor of love by volunteers. Thank you very much to the
team of "hackers in the public interest" who make Tahoe-LAFS
possible.
-Zooko Wilcox-O'Hearn
+Brian Warner
on behalf of the Tahoe-LAFS team
-September 13, 2011
-Boulder, Colorado, USA
+October 31, 2011
+San Francisco, California, USA
[1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/relnotes.txt?rev=5164
-[2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/1.8.3/NEWS.rst?rev=5014
+[2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS.rst?rev=5352
[3] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst
[4] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects
[5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL
[7] https://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.rst
[8] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
[9] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap
-[10] https://tahoe-lafs.org/trac/tahoe-lafs/browser/1.8.3/CREDITS?rev=5003
+[10] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5352
[11] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev
[12] https://tahoe-lafs.org/hacktahoelafs/
projects / tahoe-lafs / tahoe-lafs.git / commitdiff