X-Git-Url: https://git.rkrishnan.org/?a=blobdiff_plain;f=relnotes.txt;h=d7f671b36d08de07f1a0cf0742349962f41b43fd;hb=HEAD;hp=a8ec29f3932469b07274e487f040a0b63be60e70;hpb=a4e6288e33dcd3614bb0ff4e33139e1f691c144e;p=tahoe-lafs%2Ftahoe-lafs.git diff --git a/relnotes.txt b/relnotes.txt index a8ec29f3..d7f671b3 100644 --- a/relnotes.txt +++ b/relnotes.txt @@ -1,213 +1,164 @@ -NEW VERSION RELEASED +ANNOUNCING Tahoe, the Least-Authority File Store, v1.10.2 -We are pleased to announce the release of version 0.5 of allmydata.org -"Tahoe", a secure, decentralized storage grid under a free-software -licence. This is the follow-up to v0.4 which was released June 29, -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 then we've made several improvements, including: +https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst - * a RESTful API for programming your Tahoe node in the language of - your choice [2] +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: - * a command-line interface in the Unix style for uploading and - downloading files (ticket #53) +https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst - * ported to Solaris +The previous stable release of Tahoe-LAFS was v1.10.1, released +on June 15, 2015. - * reduced the memory used when uploading large files (ticket #29) - - * reduced the bandwidth and disk space used when uploading many small - files (tickets #80, 81, #85) - - * added configurable erasure-coding parameters: how many total shares - to produce, and how many shares are required to reconstruct the - file (ticket #84) - - * added configurable limits on how much disk space your node will - allocate for storing data on behalf of other peers (ticket #34) - - * many bugs fixed and enhancements implemented - -For complete details, see this web page which shows all ticket -changes, repository checkins, and wiki changes from June 29 to today, -August 17: [3]. - -Allmydata.org Tahoe v0.5 is incompatible with v0.4 due to a change in -the formatting of URIs to make them more human-friendly. +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.) +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. -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 [4]. -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. +LICENCE +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. -LICENCE +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. -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. +(You may choose to use this package under the terms of either +licence, at your option.) INSTALLATION -This release of Tahoe works on Linux, Mac OS X, Windows, Cygwin, and -Solaris. +Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD, +and probably most other systems. Start with +"docs/quickstart.rst" [6]. + -To install, download the tarball [5], untar it, go into the resulting -directory, and follow the directions in the README [6]. +HACKING AND COMMUNITY +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. -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. +SPONSORSHIP -Each client node runs 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 +Atlas Networks has contributed several hosted servers for +performance testing. Thank you to Atlas Networks [11] for +their generous and public-spirited support. -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. +And a special thanks to Least Authority Enterprises [12], +which employs several Tahoe-LAFS developers, for their +continued support. -USAGE - command-line interface +HACK TAHOE-LAFS! -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. +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]. -USAGE - other -You can control the filesystem through the RESTful web API [2]. Other -ways to access the filesystem are planned: please see the roadmap.txt -[7] for some plans. +ACKNOWLEDGEMENTS +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. -HACKING AND COMMUNITY +Brian Warner +on behalf of the Tahoe-LAFS team + +July 30, 2015 +San Francisco, California, USA -Please join the mailing list [8] to discuss the ideas behind Tahoe and -extensions of and uses of Tahoe. Patches that extend and improve -Tahoe are gratefully accepted -- roadmap.txt shows the next -improvements that we plan to make and CREDITS lists the names of -people who've contributed to the project. You can browse the revision -control history, source code, and issue tracking at the Trac instance -[9]. Please see the buildbot [10], which shows how Tahoe builds and -passes unit tests on each checkin, and the code coverage results [11] -and percentage-covered graph [12], which show how much of the Tahoe -source code is currently exercised by the test suite. - - -NETWORK ARCHITECTURE - -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. - -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. - -A single distinct server called a "vdrive server" maintains a global -mapping from pathnames/filenames to URIs. - -We are acutely aware of the limitations of 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 should be -able to set up a private grid for you and your friends almost as -easily as to connect to our public test grid. - - -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. - -Tahoe is based on the Foolscap library [13] which provides a remote -object protocol inspired by the capability-secure "E" programming -language [14]. 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. - -The network layer is provided by the Twisted library [15]. -Computationally intensive operations are performed in native compiled -code, such as the "zfec" library for fast erasure coding (also -available separately: [16]). - -Tahoe is sponsored by Allmydata, Inc. [17], 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 -on behalf of the allmydata.org Tahoe team -August 17, 2007 -Grand Junction, Colorado - - -[1] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=849 -[2] http://allmydata.org/trac/tahoe/browser/docs/webapi.txt -[3] http://allmydata.org/trac/tahoe/timeline?from=2007-08-17&daysback=51&changeset=on&ticket=on&wiki=on&update=Update -[4] http://allmydata.org/trac/tahoe/wiki/UseCases -[5] http://allmydata.org/source/tahoe/tahoe-0.5.tar.gz -[6] http://allmydata.org/trac/tahoe/browser/README?rev=1102 -[7] http://allmydata.org/trac/tahoe/browser/roadmap.txt -[8] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev -[9] http://allmydata.org/trac/tahoe -[10] http://allmydata.org/buildbot -[11] http://allmydata.org/tahoe-figleaf/figleaf/ -[12] http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_figleaf.html -[13] http://twistedmatrix.com/trac/wiki/FoolsCap -[14] http://erights.org/ -[15] http://twistedmatrix.com/ -[16] http://allmydata.org/trac/tahoe/browser/src/zfec -[17] 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