-NEW VERSION RELEASED -- Allmydata-Tahoe version 0.6
+ANNOUNCING Tahoe, the Least-Authority File Store, v1.10.2
-We are pleased to announce the release of version 0.6 of allmydata.org
-"Tahoe", a secure, decentralized storage grid under a free-software
-licence. This is the successor to v0.5.1, which was released
-August 23, 2007 (see [1]).
+The Tahoe-LAFS team is pleased to announce version 1.10.2 of
+Tahoe-LAFS, an extremely reliable decentralized storage system.
+Get it here:
-Since v0.5.1 we've made the following changes:
+https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst
- * Distribute shares more evenly onto servers -- this makes files more
- reliable when there are few servers. (ticket #132)
+Tahoe-LAFS is the first distributed storage system to offer
+"provider-independent security" — meaning that not even the
+operators of your storage servers can read or alter your data
+without your consent. Here is the one-page explanation of its
+unique security and fault-tolerance properties:
- * Package Tahoe with setuptools/easy_install. This makes it so that
- other libraries that Tahoe depends upon get automatically installed
- when Tahoe is installed. It also means that people who have Python
- and the easy_install tool can execute "easy_install
- allmydata-tahoe" on the command-line (including on Windows), and it
- will download and install Tahoe. (tickets #82, 93, 130)
+https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst
- * Memory usage during download now remains low, even if your node is
- streaming the downloaded content to a slow web browser over
- HTTP. (ticket #129)
+The previous stable release of Tahoe-LAFS was v1.10.1, released
+on June 15, 2015.
- * Shares have a version number in them so that in the future we can
- upgrade the share format without losing old data. (ticket #90)
-
- * improved logging, thanks to Arno
-
- * Shares now contain leases, which gives us the information to
- compute which shares are safe to delete, but we haven't yet
- implemented deletion itself. Eventually, this will enable client
- quota tracking. (tickets #119, #67)
-
-
-We also fixed other bugs and implemented other improvements. For
-complete details, see this web page which shows all ticket changes,
-repository checkins, and wiki changes from August 24 to today,
-September 24: [2].
-
-Allmydata.org Tahoe v0.6 is incompatible with Allmydata.org Tahoe
-v0.5.1 because of the share format version number and the leases.
+v1.10.2 is a small bugfix release, which fixes a critical
+packaging error that prevented v1.10.1 from building against the
+latest version of the upstream "mock" library. A few small bugs
+were fixed too. See the NEWS file [1] for details.
WHAT IS IT GOOD FOR?
-With Tahoe, you can store your files in a distributed way across a set
-of computers, such that if some of the computers fail or become
-unavailable, you can still retrieve your data from the remaining
-computers. You can also securely share your files with other users.
-
-This release is targeted at hackers and users who are willing to use a
-text-oriented web user interface, or a command-line user interface.
-(Or a RESTful API. Just telnet to localhost and type HTTP requests to
-get started.)
-
-Because this software is new, it is not yet recommended for storage of
-highly confidential data nor for important data which is not otherwise
-backed up. Given that caveat, this software works and there are no
-known security flaws which would compromise confidentiality or data
-integrity.
-
-This release of Tahoe is suitable for the "friendnet" use case [3].
-It is easy to set up a private grid which is securely shared among a
-specific, limited set of friends. Files uploaded to this shared grid
-will be available to all friends, even when some of the computers are
-unavailable. It is also easy to encrypt individual files and
-directories so that only designated recipients can read them.
+With Tahoe-LAFS, you distribute your data across multiple
+servers. Even if some of the servers fail or are taken over
+by an attacker, the entire file store continues to function
+correctly, preserving your privacy and security. You can
+easily share specific files and directories with other people.
+
+In addition to the core storage system itself, volunteers
+have built other projects on top of Tahoe-LAFS and have
+integrated Tahoe-LAFS with existing systems, including
+Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django,
+Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and
+more. See the Related Projects page on the wiki [3].
+
+We believe that strong cryptography, Free and Open Source
+Software, erasure coding, and principled engineering practices
+make Tahoe-LAFS safer than RAID, removable drive, tape,
+on-line backup or cloud storage.
+
+This software is developed under test-driven development, and
+there are no known bugs or security flaws which would
+compromise confidentiality or data integrity under recommended
+use. (For all important issues that we are currently aware of
+please see the known_issues.rst file [2].)
+
+
+COMPATIBILITY
+
+This release should be compatible with the version 1 series of
+Tahoe-LAFS. Clients from this release can write files and
+directories in the format used by clients of all versions back
+to v1.0 (which was released March 25, 2008). Clients from this
+release can read files and directories produced by clients of
+all versions since v1.0. Servers from this release can serve
+clients of all versions back to v1.0 and clients from this
+release can use servers of all versions back to v1.0.
+
+Except for the new optional MDMF format, we have not made any
+intentional compatibility changes. However we do not yet have
+the test infrastructure to continuously verify that all new
+versions are interoperable with previous versions. We intend
+to build such an infrastructure in the future.
+
+The new Introducer protocol added in v1.10 is backwards
+compatible with older clients and introducer servers, however
+some features will be unavailable when an older node is
+involved. Please see docs/nodekeys.rst [14] for details.
+
+This is the nineteenth release in the version 1 series. This
+series of Tahoe-LAFS will be actively supported and maintained
+for the foreseeable future, and future versions of Tahoe-LAFS
+will retain the ability to read and write files compatible
+with this series.
LICENCE
-Tahoe is offered under the GNU General Public License (v2 or later),
-with the added permission that, if you become obligated to release a
-derived work under this licence (as per section 2.b), you may delay
-the fulfillment of this obligation for up to 12 months. If you are
-obligated to release code under section 2.b of this licence, you are
-obligated to release it under these same terms, including the 12-month
-grace period clause.
-
-
-INSTALLATION
+You may use this package under the GNU General Public License,
+version 2 or, at your option, any later version. See the file
+"COPYING.GPL" [4] for the terms of the GNU General Public
+License, version 2.
-Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris. For
-installation instructions please see the README [4].
+You may use this package under the Transitive Grace Period
+Public Licence, version 1 or, at your option, any later
+version. (The Transitive Grace Period Public Licence has
+requirements similar to the GPL except that it allows you to
+delay for up to twelve months after you redistribute a derived
+work before releasing the source code of your derived work.)
+See the file "COPYING.TGPPL.rst" [5] for the terms of the
+Transitive Grace Period Public Licence, version 1.
+(You may choose to use this package under the terms of either
+licence, at your option.)
-USAGE - web interface
-Once installed, create a "client node". Instruct this client node to
-connect to a specific "introducer node" by means of config files in
-the client node's working directory. To join a grid, copy in the
-.furl files for that grid. To create a private grid, run your own
-introducer, and copy its .furl files. See the README for step-by-step
-instructions.
-
-Each client node can run a local webserver (enabled by writing the
-desired port number into a file called 'webport'). The welcome page
-of this webserver shows the node's status, including which introducer
-is being used and which other nodes are connected.
-
-Links from the welcome page lead to other pages that give access to a
-virtual filesystem, in which each directory is represented by a
-separate page. Each directory page shows a list of the files
-available there, with download links, and forms to upload new files.
-
-USAGE - command-line interface
-
-Run "allmydata-tahoe ls [VIRTUAL PATH NAME]" to list the contents of a
-virtual directory. Run "allmydata-tahoe get [VIRTUAL FILE NAME]
-[LOCAL FILE NAME]" to download a file. Run "allmydata-tahoe put
-[LOCAL FILE NAME] [VIRTUAL FILE NAME]" to upload a file. Run
-"allmydata-tahoe rm [VIRTUAL PATH NAME]" to unlink a file or directory
-in the virtual drive.
-
-USAGE - other
+INSTALLATION
-You can control the filesystem through the RESTful web API [5]. Other
-ways to access the filesystem are planned: please see the
-roadmap.txt [6] for some plans.
+Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD,
+and probably most other systems. Start with
+"docs/quickstart.rst" [6].
HACKING AND COMMUNITY
-Please join the mailing list [7] to discuss the ideas behind Tahoe and
-extensions of and uses of Tahoe. Patches that extend and improve
-Tahoe are gratefully accepted -- roadmap.txt [6] shows the next
-improvements that we plan to make and CREDITS [8] lists the names of
-people who've contributed to the project. The wiki Dev page [9]
-collects various hacking resources including revision history
-browsing, automated test results (including code coverage), automated
-performance tests, graphs of how many people are using the public test
-grid for how many files, and more.
-
-
-NETWORK ARCHITECTURE
+Please join us on the mailing list [7]. Patches are gratefully
+accepted -- the RoadMap page [8] shows the next improvements
+that we plan to make and CREDITS [9] lists the names of people
+who've contributed to the project. The Dev page [10] contains
+resources for hackers.
-Each peer maintains a connection to each other peer. A single
-distinct server called an "introducer" is used to discover other peers
-with which to connect.
-To store a file, the file is encrypted and erasure coded, and each
-resulting share is uploaded to a different peer. The secure hash of
-the encrypted file and the encryption key are packed into a URI,
-knowledge of which is necessary and sufficient to recover the file.
+SPONSORSHIP
-To fetch a file, starting with the URI, a subset of shares is
-downloaded from peers, the file is reconstructed from the shares, and
-then decrypted.
+Atlas Networks has contributed several hosted servers for
+performance testing. Thank you to Atlas Networks [11] for
+their generous and public-spirited support.
-A single distinct server called a "vdrive server" maintains a global
-mapping from pathnames/filenames to URIs.
+And a special thanks to Least Authority Enterprises [12],
+which employs several Tahoe-LAFS developers, for their
+continued support.
-We are acutely aware of the limitations on decentralization and
-scalability inherent in this version. In particular, the
-completely-connected property of the grid and the requirement of a
-single distinct introducer and vdrive server limits the possible size
-of the grid. We have plans to loosen these limitations (see
-roadmap.txt). Currently it should be noted that the grid already
-depends as little as possible on the accessibility and correctness of
-the introduction server and the vdrive server. Also note that the
-choice of which servers to use is easily configured -- you can set up
-a private grid for you and your friends as easily as connecting to our
-public test grid.
+HACK TAHOE-LAFS!
+If you can find a security flaw in Tahoe-LAFS which is serious
+enough that we feel compelled to warn our users and issue a fix,
+then we will award you with a customized t-shirt with your
+exploit printed on it and add you to the "Hack Tahoe-LAFS Hall
+Of Fame" [13].
-SOFTWARE ARCHITECTURE
-Tahoe is a "from the ground-up" rewrite, inspired by Allmydata's
-existing consumer backup service. It is primarily written in the
-Python programming language.
+ACKNOWLEDGEMENTS
-Tahoe is based on the Foolscap library [10] which provides a remote
-object protocol inspired by the capability-secure "E" programming
-language [11]. Foolscap allows us to express the intended behavior of
-the distributed grid directly in object-oriented terms while relying
-on a well-engineered, secure transport layer.
+This is the fourteenth release of Tahoe-LAFS to be created
+solely as a labor of love by volunteers. Thank you very much
+to the team of "hackers in the public interest" who make
+Tahoe-LAFS possible.
-The network layer is provided by the Twisted library [12].
-Computationally intensive operations are performed in native compiled
-code, such as the "zfec" library for fast erasure coding (also
-available separately: [13]).
+Brian Warner
+on behalf of the Tahoe-LAFS team
+July 30, 2015
+San Francisco, California, USA
-SPONSORSHIP
-Tahoe is sponsored by Allmydata, Inc. [14], a provider of consumer
-backup services. Allmydata, Inc. contributes hardware, software,
-ideas, bug reports, suggestions, demands, and money (employing several
-allmydata.org Tahoe hackers and allowing them to spend part of their
-work time on the next-generation, free-software project). We are
-eternally grateful!
-
-
-Zooko O'Whielacronx and Brian Warner
-on behalf of the allmydata.org Tahoe team
-September 24, 2007
-Boulder, Colorado and San Francisco, California
-
-
-[1] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=1154
-[2] http://allmydata.org/trac/tahoe/timeline?from=2007-09-24&daysback=30&changeset=on&milestone=on&ticket=on&ticket_details=on&wiki=on&update=Update
-[3] http://allmydata.org/trac/tahoe/wiki/UseCases
-[4] http://allmydata.org/trac/tahoe/browser/README?rev=1333
-[5] http://allmydata.org/trac/tahoe/browser/docs/webapi.txt?rev=1151
-[6] http://allmydata.org/trac/tahoe/browser/roadmap.txt
-[7] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
-[8] http://allmydata.org/trac/tahoe/browser/CREDITS?rev=1270
-[9] http://allmydata.org/trac/tahoe/wiki/Dev
-[10] http://twistedmatrix.com/trac/wiki/FoolsCap
-[11] http://erights.org/
-[12] http://twistedmatrix.com/
-[13] http://allmydata.org/source/zfec/zfec/
-[14] http://allmydata.com
+[1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst
+[2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst
+[3] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects
+[4] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL
+[5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst
+[6] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst
+[7] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
+[8] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap
+[9] https://tahoe-lafs.org/trac/tahoe-lafs/browser/CREDITS
+[10] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev
+[11] http://atlasnetworks.us/
+[12] https://leastauthority.com/
+[13] https://tahoe-lafs.org/hacktahoelafs/
+[14] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/nodekeys.rst
projects / tahoe-lafs / tahoe-lafs.git / blobdiff