From: Brian Warner Date: Mon, 31 Oct 2011 03:24:39 +0000 (-0700) Subject: update relnotes, rotate known_issues, for 1.9 X-Git-Tag: allmydata-tahoe-1.9.0~4 X-Git-Url: https://git.rkrishnan.org/vdrive/status?a=commitdiff_plain;h=527400b9bf5c93e10ea86c504711871aef1cf51e;p=tahoe-lafs%2Ftahoe-lafs.git update relnotes, rotate known_issues, for 1.9 --- diff --git a/docs/historical/historical_known_issues.txt b/docs/historical/historical_known_issues.txt index 88e1fccd..3756d6ce 100644 --- a/docs/historical/historical_known_issues.txt +++ b/docs/historical/historical_known_issues.txt @@ -9,6 +9,88 @@ Issues in newer releases of Tahoe-LAFS can be found at: 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 == diff --git a/docs/known_issues.rst b/docs/known_issues.rst index 066f50df..8aecccab 100644 --- a/docs/known_issues.rst +++ b/docs/known_issues.rst @@ -14,9 +14,8 @@ want to read `the "historical known issues" document`_. .. _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`_ @@ -24,88 +23,6 @@ Issues in Tahoe-LAFS v1.8.2, released 2011-01-30 * `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 diff --git a/relnotes.txt b/relnotes.txt index 5d02268a..282535fc 100644 --- a/relnotes.txt +++ b/relnotes.txt @@ -1,10 +1,10 @@ -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 @@ -12,13 +12,13 @@ operators of your storage servers can read or alter your data 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? @@ -60,7 +60,7 @@ all versions since v1.0. Servers from this release can serve 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 @@ -105,9 +105,9 @@ resources for hackers. 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! @@ -121,20 +121,20 @@ Of Fame" [12]. 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 @@ -142,6 +142,6 @@ Boulder, Colorado, USA [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/