more docs updates

docs/known_issues.rst

@@ -15,6 +15,7 @@ want to read `the "historical known issues" document`_.
 
 
 Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
+=======================================================
 
   *  `Potential unauthorized access by JavaScript in unrelated files`_
   *  `Potential disclosure of file through embedded hyperlinks or JavaScript in that file`_
@@ -239,3 +240,87 @@ Attackers can combine the above information with inferences based on timing
 correlations. For instance, two files that are accessed close together in
 time are likely to be related even if they are not linked in the directory
 structure. Also, users that access the same files may be related to each other.
+
+
+Known Issues in Tahoe-LAFS 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

docs/quickstart.rst

@@ -21,8 +21,7 @@ might not be easy to set up on your platform. If the following
 instructions don't Just Work without any further effort on your part,
 then please write to `the tahoe-dev mailing list
 <https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev>`_ where
-friendly hackers will help you out. You might also find clues in the
+friendly hackers will help you out.
-`Advanced Installation`_ section described below.
 
 Install Python
 --------------

relnotes.txt

@@ -15,12 +15,12 @@ unique security and fault-tolerance properties:
 https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst
 
 The previous stable release of Tahoe-LAFS was v1.8.3, which was
-released September 13, 2011 [1].
+released September 13, 2011.
 
 v1.9.0 offers a new mutable-file format (more efficient for
 large files), a file-blacklisting feature, and a new
-"drop-upload" feature. See the NEWS file [2] and
+"drop-upload" feature. See the NEWS file [3] and
-known_issues.rst [3] file for details.
+known_issues.rst [4] file for details.
 
 
 WHAT IS IT GOOD FOR?
@@ -37,7 +37,7 @@ have built other projects on top of Tahoe-LAFS and have
 integrated Tahoe-LAFS with existing systems, including
 Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django,
 Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and
-more. See the Related Projects page on the wiki [4].
+more. See the Related Projects page on the wiki [5].
 
 We believe that strong cryptography, Free and Open Source
 Software, erasure coding, and principled engineering practices
@@ -48,7 +48,7 @@ This software is developed under test-driven development, and
 there are no known bugs or security flaws which would
 compromise confidentiality or data integrity under recommended
 use. (For all important issues that we are currently aware of
-please see the known_issues.rst file [3].)
+please see the known_issues.rst file [2].)
 
 
 COMPATIBILITY
@@ -73,7 +73,7 @@ LICENCE
 
 You may use this package under the GNU General Public License,
 version 2 or, at your option, any later version. See the file
-"COPYING.GPL" [5] for the terms of the GNU General Public
+"COPYING.GPL" [4] for the terms of the GNU General Public
 License, version 2.
 
 You may use this package under the Transitive Grace Period
@@ -82,7 +82,7 @@ version. (The Transitive Grace Period Public Licence has
 requirements similar to the GPL except that it allows you to
 delay for up to twelve months after you redistribute a derived
 work before releasing the source code of your derived work.)
-See the file "COPYING.TGPPL.rst" [6] for the terms of the
+See the file "COPYING.TGPPL.rst" [5] for the terms of the
 Transitive Grace Period Public Licence, version 1.
 
 (You may choose to use this package under the terms of either
@@ -93,24 +93,27 @@ INSTALLATION
 
 Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD,
 and probably most other systems. Start with
-"docs/quickstart.rst" [7].
+"docs/quickstart.rst" [6].
 
 
 HACKING AND COMMUNITY
 
-Please join us on the mailing list [8]. Patches are gratefully
+Please join us on the mailing list [7]. Patches are gratefully
-accepted -- the RoadMap page [9] shows the next improvements
+accepted -- the RoadMap page [8] shows the next improvements
-that we plan to make and CREDITS [10] lists the names of people
+that we plan to make and CREDITS [9] lists the names of people
-who've contributed to the project. The Dev page [11] contains
+who've contributed to the project. The Dev page [10] contains
 resources for hackers.
 
 
 SPONSORSHIP
 
 Atlas Networks has contributed several hosted servers for
-performance testing. Thank you to Atlas Networks for their
+performance testing. Thank you to Atlas Networks [11] for
-generous and public-spirited support.
+their generous and public-spirited support.
 
+And a special thanks to Least Authority Enterprises [12],
+which employs several Tahoe-LAFS developers, for their
+continued support.
 
 HACK TAHOE-LAFS!
 
@@ -118,7 +121,7 @@ If you can find a security flaw in Tahoe-LAFS which is serious
 enough that we feel compelled to warn our users and issue a fix,
 then we will award you with a customized t-shirts with your
 exploit printed on it and add you to the "Hack Tahoe-LAFS Hall
-Of Fame" [12].
+Of Fame" [13].
 
 
 ACKNOWLEDGEMENTS
@@ -135,15 +138,16 @@ October 31, 2011
 San Francisco, California, USA
 
 
-[1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/relnotes.txt?rev=5164
+[1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS.rst?rev=5356
-[2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS.rst?rev=5352
+[2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst
-[3] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst
+[3] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects
-[4] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects
+[4] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL
-[5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL
+[5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst
-[6] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst
+[6] https://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.rst
-[7] https://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.rst
+[7] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
-[8] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
+[8] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap
-[9] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap
+[9] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5356
-[10] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5352
+[10] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev
-[11] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev
+[11] http://atlasnetworks.us/
-[12] https://tahoe-lafs.org/hacktahoelafs/
+[12] http://leastauthority.com/
+[13] https://tahoe-lafs.org/hacktahoelafs/