known_issues, quickstart: add version and anticipated release date

[tahoe-lafs/tahoe-lafs.git] / docs / known_issues.rst

diff --git a/docs/known_issues.rst b/docs/known_issues.rst
index f0e44ffd06103e6ff8fefaf438b944896d75157c..65610bc547090e775825677c884078d0db27ad93 100644 (file)
--- a/docs/known_issues.rst
+++ b/docs/known_issues.rst
@@ -18,7 +18,7 @@ want to read `the "historical known issues" document`_.
 .. _the "historical known issues" document: historical/historical_known_issues.txt
 
 
 .. _the "historical known issues" document: historical/historical_known_issues.txt
 
 

-Known Issues in Tahoe-LAFS v1.9.2, released 2-Jul-2012
+Known Issues in Tahoe-LAFS v1.10, released 01-May-2013

 ======================================================
 
   *  `Unauthorized access by JavaScript in unrelated files`_
 ======================================================
 
   *  `Unauthorized access by JavaScript in unrelated files`_


@@ -27,6 +27,7 @@ Known Issues in Tahoe-LAFS v1.9.2, released 2-Jul-2012
   *  `Capabilities may be leaked to web browser phishing filter / "safe browsing" servers`_
   *  `Known issues in the FTP and SFTP frontends`_
   *  `Traffic analysis based on sizes of files/directories, storage indices, and timing`_
   *  `Capabilities may be leaked to web browser phishing filter / "safe browsing" servers`_
   *  `Known issues in the FTP and SFTP frontends`_
   *  `Traffic analysis based on sizes of files/directories, storage indices, and timing`_

+  *  `Privacy leak via Google Chart API link in map-update timing web page`_

 
 ----
 
 
 ----
 


@@ -252,6 +253,48 @@ 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.
 
 
 structure. Also, users that access the same files may be related to each other.
 
 

+----
+
+Privacy leak via Google Chart API link in map-update timing web page
+--------------------------------------------------------------------
+
+The Tahoe web-based user interface includes a diagnostic page known as the
+"map-update timing page". It is reached through the "Recent and Active
+Operations" link on the front welcome page, then through the "Status" column
+for "map-update" operations (which occur when mutable files, including
+directories, are read or written). This page contains per-server response
+times, as lines of text, and includes an image which displays the response
+times in graphical form. The image is generated by constructing a URL for the
+`Google Chart API <https://developers.google.com/chart/image/>`_, which is
+then served by the `chart.apis.google.com` internet server.
+
+When you view this page, several parties may learn information about your
+Tahoe activities. The request will typically include a "Referer" header,
+revealing the URL of the mapupdate status page (which is typically something
+like "http://127.0.0.1:3456/status/mapupdate-123") to network observers and
+the Google API server. The image returned by this server is typically a PNG
+file, but either the server or a MitM attacker could replace it with
+something malicious that attempts to exploit a browser rendering bug or
+buffer overflow. (Note that browsers do not execute scripts inside IMG tags,
+even for SVG images).
+
+In addition, if your Tahoe node connects to its grid over Tor or i2p, but the
+web browser you use to access your node does not, then this image link may
+reveal your use of Tahoe (and that grid) to the outside world. It is not
+recommended to use a browser in this way, because other links in Tahoe-stored
+content would reveal even more information (e.g. an attacker could store an
+HTML file with unique CSS references into a shared Tahoe grid, then send your
+pseudonym a message with its URI, then observe your browser loading that CSS
+file, and thus link the source IP address of your web client to that
+pseudonym).
+
+A future version of Tahoe will probably replace the Google Chart API link
+(which was deprecated by Google in April 2012) with client-side javascript
+using d3.js, removing the information leak but requiring JS to see the chart.
+See ticket `#1942`_ for details.
+
+.. _#1942: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1942
+

 ----
 
 Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
 ----
 
 Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011


@@ -318,7 +361,7 @@ authorization (confidentiality), nor to change the contents of a file
 
 A person could learn the storage index of a file in several ways:
 
 
 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
+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.
 
    granted a read capability to the file. They can determine the file's
    storage index from its read capability.
 


@@ -347,17 +390,17 @@ 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
 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 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
 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.
+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
 
 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