From 20ae6bdc57ae8baf8f3964bb233ee9b15d3e8603 Mon Sep 17 00:00:00 2001 From: Zooko O'Whielacronx <zooko@zooko.com> Date: Tue, 21 Jul 2009 16:43:11 -0700 Subject: [PATCH] docs: update NEWS, about.html, relnotes-short.txt, and known_issues.txt in preparation for v1.5.0 Especially note that strong claims of specialness that I've added, e.g. in about.html . --- NEWS | 13 ++++++++----- docs/about.html | 19 ++++++++++++------- docs/known_issues.txt | 14 +++++++------- relnotes-short.txt | 15 +++++++++------ 4 files changed, 36 insertions(+), 25 deletions(-) diff --git a/NEWS b/NEWS index 70781631..7ad22c01 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,6 @@ User visible changes in Tahoe. -*- outline -*- -* Release 1.XXX (200X-YY-ZZ) +* Release 1.5.0 (2009-07-22) ** Improvements @@ -17,14 +17,16 @@ makeover by Kevin Reid, making it much prettier and easier to read. The WUI mirroring the CLI --add-lease option, so leases can be added or renewed from the web interface. +The CLI "tahoe mv" command refuses to overwrite directories. (#705) + The CLI "tahoe webopen" command, when run without arguments, will bring up the "Welcome Page" (node status and mkdir/upload forms). The 3.5MB limit on mutable files was removed, so it should be possible to upload arbitrarily-sized mutable files. Note, however, that the data format -and algorithm remains the same, so larger files will suffer from poor speed, -data transfer overhead, memory consumption, and alacrity until "MDMF" mutable -files (#393) are implemented. (#694) +and algorithm remains the same, so using mutable files still requires +bandwidth, computation, and RAM in proportion to the size of the mutable file. +(#694) This version of Tahoe will tolerate directory entries that contain filecap formats which it does not recognize: files and directories from the future. @@ -51,7 +53,8 @@ the Helper's ability to mount a partial-information-guessing attack. (#722) ** Platform/packaging changes -Tahoe now runs on NetBSD. +Tahoe-LAFS now runs on NetBSD, OpenBSD, and ArchLinux, and an embedded system +based on an ARM CPU running at 266 MHz. XXX Unit test timeouts have been raised to allow the tests to complete on extremely slow platforms like embedded ARM-based NAS boxes. An ARM-specific diff --git a/docs/about.html b/docs/about.html index c0b1cbac..de8834a5 100644 --- a/docs/about.html +++ b/docs/about.html @@ -1,21 +1,26 @@ <!DOCtype HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html lang="en"> <head> - <title>Welcome To Tahoe</title> + <title>Welcome To Tahoe-LAFS</title> <link rev="made" class="mailto" href="mailto:zooko[at]zooko[dot]com"> - <meta name="description" content="welcome to Tahoe"> + <meta name="description" content="welcome to Tahoe-LAFS"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> - <meta name="keywords" content="tahoe secure decentralized filesystem installation"> + <meta name="keywords" content="tahoe secure decentralized filesystem cloud storage"> </head> <body> - <h1>Welcome to Tahoe</h1> - <p>Welcome to allmydata.org Tahoe, the Least-Authority Filesystem. This is a secure, decentralized, fault-tolerant filesystem. All of the source code is available under a choice of two Free Software, Open Source licences.</p> - <p>This filesystem is encrypted and spread over multiple peers in such a way that it continues to function even when some of the peers are unavailable, malfunctioning, or malicious.</p> + <h1>Welcome to Tahoe-LAFS</h1> + <p>Welcome to Tahoe, the Least-Authority Filesystem. Tahoe-LAFS is the only secure cloud storage system. All of the source code is available under a choice of two Free Software, Open Source licences.</p> + <h2>The only secure cloud storage system?</h2> + <p>Every seller of cloud storage services will tell you that their service is secure. But what they mean by that is something fundamentally different from what we mean. What they mean by "secure" is that they try really hard not to misuse the power to read or alter your data. This turns out to be hard. Bugs, misconfigurations, and operator error can accidentally expose your data to another customer or to the public, or can corrupt your data. Criminals routinely gain illicit access to corporate servers. Most insidiously of all, employees of the service provider itself may read or alter your data out of carelessness, avarice, or mere curiousity. The most conscientious of these service providers spend considerable effort and expense trying to mitigate these threats.</p> + <p>What we mean by "security" is something different. <em>The service provider never has the ability to read or alter your data in the first place.</em> Never. If you store your data with Tahoe-LAFS, then all of the threats above are non-issues to you. Not only is it easy for the service provider to avoid exposing or corrupting your data, but in fact they couldn't do so if they tried.</p> + <p>Here's how it works.</p> <img src="http://allmydata.org/~zooko/network-and-reliance-topology.png"></img> <p>(See also <a href="http://testgrid.allmydata.org:3567/file/URI:CHK:4rd7ous7b5xgbmpan6mmdbx3za:2jywqfnobreondkanwnekugmxv3cyuzdv34fpyazkb5htjmokdta:3:10:102761/@@named=/network-and-reliance-topology-paranoid.png">Tahoe-LAFS for Paranoids</a> and <a href="http://testgrid.allmydata.org:3567/file/URI:CHK:mpa737uu7suao7lva2axhbtgw4:5rpemho4d3cqsgvgsqmg3hbn2mzeibsbdpthmpyo5jwnj7f2fqfa:3:10:114022/@@named=/network-and-reliance-topology-corporate.png">Tahoe-LAFS for Corporates</a>.)</p> + <p>The filesystem is encrypted and spread over multiple servers in such a way that it continues to function even when some of the servers are unavailable, malfunctioning, or malicious.</p> + <p>A "storage grid" is made up of a number of storage servers. A storage server has local attached storage (typically one or more hard disks). A "gateway" uses the storage servers and provides access to the filesystem over HTTP(S) or (S)FTP.</p> <p>Users do not rely on storage servers to provide <i>confidentiality</i> nor <i>integrity</i> for their data -- instead all of the data is encrypted and integrity-checked by the gateway, so that the servers can neither read nor alter the contents of the files.</p> <p>Users rely on storage servers for <i>availability</i>. The ciphertext is erasure-coded and distributed across <cite>N</cite> storage servers (the default value for <cite>N</cite> is 10) so that it can be recovered from any <cite>K</cite> of these servers (the default value of <cite>K</cite> is 3). Therefore only the simultaneous failure of <cite>N-K+1</cite> (with the defaults, 8) servers can make the data unavailable.</p> @@ -29,7 +34,7 @@ <p>For more technical detail, please see <a href="architecture.txt">architecture.txt</a> and the <a href="http://allmydata.org/trac/tahoe/wiki/Doc">The Doc Page</a> on the Wiki.</p> <h2>Installing</h2> - <p>To install Tahoe, please see <a href="install.html">install.html</a>.</p> + <p>To install Tahoe-LAFS, please see <a href="install.html">install.html</a>.</p> <h2>Licence</h2> <p>You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file <a href="../COPYING.GPL">COPYING.GPL</a> for the terms of the GNU General Public License, version 2.</p> diff --git a/docs/known_issues.txt b/docs/known_issues.txt index 3e582c4e..8831f8c3 100644 --- a/docs/known_issues.txt +++ b/docs/known_issues.txt @@ -5,13 +5,13 @@ manage them. The current version of this file can be found at http://allmydata.org/source/tahoe/trunk/docs/known_issues.txt -Older versions of this document describing issues in older versions of -Tahoe-LAFS can be found at +If you've been using Tahoe-LAFS since v1.1, released 2008-06-11, or if you're +just curious about what sort of mistakes we've made in the past, then you might +want to read the "historical known issues" document: http://allmydata.org/source/tahoe/trunk/docs/historical/historical_known_issues.txt -== issues in Tahoe v1.3.0, released 2009-02-13 == - +== issues in Tahoe v1.5.0, released 2009-07-22 == === potential unauthorized access by JavaScript in unrelated files === @@ -71,7 +71,7 @@ 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. +up with the "tahoe add-alias" command. Use "tahoe create-alias" instead. ==== how to manage it ==== @@ -85,5 +85,5 @@ 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. In Tahoe v1.3.0, there is a new -"tahoe create-aliase" command that does this for you. +access to your files and directories. Starting in Tahoe-LAFS v1.3.0, there is +a "tahoe create-alias" command that does this for you. diff --git a/relnotes-short.txt b/relnotes-short.txt index 2ff4c75f..efb819a7 100644 --- a/relnotes-short.txt +++ b/relnotes-short.txt @@ -1,16 +1,19 @@ -We are pleased to announce the release of version 1.3.0 of Tahoe-LAFS. +We are pleased to announce the release of version 1.5.0 of Tahoe-LAFS. -Tahoe-LAFS is a secure, decentralized, fault-tolerant filesystem. All of the source code is available under a choice of two Free Software, Open Source licences. +Tahoe-LAFS is the only secure cloud storage technology. All of the source code is available under a choice of two Free Software, Open Source licences. -This filesystem is encrypted and distributed over multiple peers in such a way it continues to function even when some of the peers are unavailable, malfunctioning, or malicious. Users can share files with other users using a simple and flexible access control scheme. +This filesystem is encrypted and distributed over multiple servers in such a way it continues to function even when some of the servers are unavailable, malfunctioning, or malicious. Users can easily and securely share files with other users. http://allmydata.org/source/tahoe/trunk/docs/about.html -This is the successor to v1.2, which was released July 21, 2008. This is a major new release, adding a repairer, an efficient backup command, support for large files, an (S)FTP server, and much more. +This is the successor to v1.4.1, which was released April 13, 2009. This is a major new release, improving the user interface and performance and fixing a few bugs. See the release notes for details: -In addition to the many new features of Tahoe itself, a crop of related projects have sprung up, including frontends for Windows and Macintosh, two front-ends written in JavaScript, a Tahoe plugin for duplicity, a Tahoe plugin for TiddlyWiki, a project to create a new backup tool, CIFS/SMB integration, an iPhone app, and three incomplete Tahoe frontends for FUSE. See Related Projects on the wiki. +http://allmydata.org/source/tahoe/trunk/relnotes.txt + +In addition to the functionality of Tahoe-LAFS itself, a crop of related projects have sprung up to extend it and to integrate it into operating systems and applications. These include frontends for Windows, Macintosh, JavaScript, and iPhone, and plugins for duplicity, bzr, Hadoop, and TiddlyWiki, and more. See the Related Projects page on the wiki: + +http://allmydata.org/trac/tahoe/wiki/RelatedProjects Tahoe is the basis of the consumer backup product from Allmydata, Inc. -- http://allmydata.com . We believe that erasure coding, strong encryption, Free/Open Source Software and careful engineering make Tahoe safer than common alternatives, such as RAID, removable drive, tape, or "on-line storage" or "Cloud storage" systems. - -- 2.45.2