known_issues.txt: fix up the argv leakage issue -- it applies to Tahoe 1.2.0. Other...

diff --git a/docs/known_issues.txt b/docs/known_issues.txt
index 50d067285b3f9f6716a68f6279d4c7f7c58c3210..1382c66f18bf05349f2d40eac01b4a02c11d85ac 100644 (file)
--- a/docs/known_issues.txt
+++ b/docs/known_issues.txt
@@ -1,12 +1,40 @@
 = Known Issues =
 
-Below is a list of known issues in recent releases of Tahoe, and how
-to manage them.
+Below is a list of known issues in recent releases of allmydata.org
+Tahoe, the Least-Authority Filesystem, and how to manage them.  The
+current version of this file can be found at
+
+http://allmydata.org/source/tahoe/trunk/docs/known_issues.txt
+
+
+== issues in Tahoe v1.2.0, released 2008-06-21 ==
+
+=== issue 10: command-line arguments are leaked to other processes ===
+
+Remember that command-line arguments are visible to other users
+(through the 'ps' command, or the windows Process Explorer tool), so
+if you are using a Tahoe node on a shared host, other users on that
+host will be able to see (and capture) any directory caps that you set
+up with the "tahoe add-alias" command.
+
+==== how to manage it ====
+
+Bypass add-alias and edit the NODEDIR/private/aliases file directly,
+by adding a line like this:
+
+fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
+
+By entering the dircap through the editor, the command-line arguments are
+bypassed, and other users will not be able to see them. Once you've added the
+alias, no other secrets are passed through the command line, so this
+vulnerability becomes less significant: they can still see your filenames and
+other arguments you type there, but not the caps that Tahoe uses to permit
+access to your files and directories.
 
 
 == issues in Tahoe v1.1.0, released 2008-06-11 ==
 
-=== issue 10: more than one file can match an immutable file cap ===
+=== issue 9: more than one file can match an immutable file cap ===
 
 In Tahoe v1.0 and v1.1.0, a flaw in the cryptographic integrity check
 makes it possible for the original uploader of an immutable file to
@@ -22,7 +50,7 @@ get the same file.
 
 ==== how to manage it ====
 
-This was fixed in Tahoe v1.1.1, released 2008-07-21, under ticket
+This was fixed in Tahoe v1.2.0, released 2008-07-21, under ticket
 #491.  Upgrade to that release of Tahoe and then you can rely on the
 property that there is only one file that you can download using a
 given capability.  If you are still using Tahoe v1.0.0 or v1.1.0, then
@@ -33,29 +61,6 @@ capability to your friend, and he uses it to download a file, you and
 your friend could get different files.
 
 
-=== issue 9: command-line arguments are leaked to other processes ===
-
-Remember that command-line arguments are visible to other users
-(through the 'ps' command, or the windows Process Explorer tool), so
-if you are using a Tahoe node on a shared host, other users on that
-host will be able to see (and capture) any directory caps that you set
-up with the "tahoe add-alias" command.
-
-==== how to manage it ====
-
-Bypass add-alias and edit the NODEDIR/private/aliases file directly,
-by adding a line like this:
-
-fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
-
-By entering the dircap through the editor, the command-line arguments are
-bypassed, and other users will not be able to see them. Once you've added the
-alias, no other secrets are passed through the command line, so this
-vulnerability becomes less significant: they can still see your filenames and
-other arguments you type there, but not the caps that Tahoe uses to permit
-access to your files and directories.
-
-
 === issue 8: server out of space when writing mutable file ===
 
 If a v1.0 or v1.1.0 storage server runs out of disk space or is