From: Zooko O'Whielacronx Date: Tue, 22 Jul 2008 01:02:49 +0000 (-0700) Subject: known_issues.txt: fix up the argv leakage issue -- it applies to Tahoe 1.2.0. Other... X-Git-Tag: allmydata-tahoe-1.2.0~2 X-Git-Url: https://git.rkrishnan.org/pf/content/FOOURL?a=commitdiff_plain;h=5b84721c7ec215e8b5c03b9a9b9bce4a5ccacfb2;p=tahoe-lafs%2Ftahoe-lafs.git known_issues.txt: fix up the argv leakage issue -- it applies to Tahoe 1.2.0. Other editing corrections. --- diff --git a/docs/known_issues.txt b/docs/known_issues.txt index 50d06728..1382c66f 100644 --- 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