mirror of
https://github.com/tahoe-lafs/tahoe-lafs.git
synced 2025-01-18 18:56:28 +00:00
known_issues.txt: fix up the argv leakage issue -- it applies to Tahoe 1.2.0. Other editing corrections.
This commit is contained in:
parent
f285d38809
commit
5b84721c7e
@ -1,39 +1,15 @@
|
|||||||
= Known Issues =
|
= Known Issues =
|
||||||
|
|
||||||
Below is a list of known issues in recent releases of Tahoe, and how
|
Below is a list of known issues in recent releases of allmydata.org
|
||||||
to manage them.
|
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.1.0, released 2008-06-11 ==
|
== issues in Tahoe v1.2.0, released 2008-06-21 ==
|
||||||
|
|
||||||
=== issue 10: more than one file can match an immutable file cap ===
|
=== issue 10: command-line arguments are leaked to other processes ===
|
||||||
|
|
||||||
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
|
|
||||||
produce more than one immutable file matching the same capability, so
|
|
||||||
that different downloads using the same capability could result in
|
|
||||||
different files. This flaw can be exploited only by the original
|
|
||||||
uploader of an immutable file, which means that it is not a severe
|
|
||||||
vulnerability: you can still rely on the integrity check to make sure
|
|
||||||
that the file you download with a given capability is a file that the
|
|
||||||
original uploader intended. The only issue is that you can't assume
|
|
||||||
that every time you use the same capability to download a file you'll
|
|
||||||
get the same file.
|
|
||||||
|
|
||||||
==== how to manage it ====
|
|
||||||
|
|
||||||
This was fixed in Tahoe v1.1.1, 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
|
|
||||||
remember that the original uploader could produce multiple files that
|
|
||||||
match the same capability, so for example if someone gives you a
|
|
||||||
capability, and you use it to download a file, and you give that
|
|
||||||
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
|
Remember that command-line arguments are visible to other users
|
||||||
(through the 'ps' command, or the windows Process Explorer tool), so
|
(through the 'ps' command, or the windows Process Explorer tool), so
|
||||||
@ -56,6 +32,35 @@ other arguments you type there, but not the caps that Tahoe uses to permit
|
|||||||
access to your files and directories.
|
access to your files and directories.
|
||||||
|
|
||||||
|
|
||||||
|
== issues in Tahoe v1.1.0, released 2008-06-11 ==
|
||||||
|
|
||||||
|
=== 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
|
||||||
|
produce more than one immutable file matching the same capability, so
|
||||||
|
that different downloads using the same capability could result in
|
||||||
|
different files. This flaw can be exploited only by the original
|
||||||
|
uploader of an immutable file, which means that it is not a severe
|
||||||
|
vulnerability: you can still rely on the integrity check to make sure
|
||||||
|
that the file you download with a given capability is a file that the
|
||||||
|
original uploader intended. The only issue is that you can't assume
|
||||||
|
that every time you use the same capability to download a file you'll
|
||||||
|
get the same file.
|
||||||
|
|
||||||
|
==== how to manage it ====
|
||||||
|
|
||||||
|
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
|
||||||
|
remember that the original uploader could produce multiple files that
|
||||||
|
match the same capability, so for example if someone gives you a
|
||||||
|
capability, and you use it to download a file, and you give that
|
||||||
|
capability to your friend, and he uses it to download a file, you and
|
||||||
|
your friend could get different files.
|
||||||
|
|
||||||
|
|
||||||
=== issue 8: server out of space when writing mutable file ===
|
=== 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
|
If a v1.0 or v1.1.0 storage server runs out of disk space or is
|
||||||
|
Loading…
Reference in New Issue
Block a user