X-Git-Url: https://git.rkrishnan.org/?a=blobdiff_plain;f=relnotes.txt;h=d7f671b36d08de07f1a0cf0742349962f41b43fd;hb=HEAD;hp=ee56ee6fe636384a7274308d549e89329aa8b1b0;hpb=19ce28e71a7d50a8c64e1c8f022c863816c7a11f;p=tahoe-lafs%2Ftahoe-lafs.git diff --git a/relnotes.txt b/relnotes.txt index ee56ee6f..d7f671b3 100644 --- a/relnotes.txt +++ b/relnotes.txt @@ -1,220 +1,164 @@ -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 - * 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) +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: - * We did performance profiling of various kinds -- upload/download - throughput, memory usage, CPU usage, storage efficiency. The - results showed that the current version is reasonably efficient on - those metrics, for the loads that we tested. See The Performance - Page [2] for details. +https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst - * Distribute shares more evenly onto servers -- this makes files more - reliable when there are few servers. (ticket #132) +The previous stable release of Tahoe-LAFS was v1.10.1, released +on June 15, 2015. - * 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) - - * 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: [3]. - -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 [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. +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 - -Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris. For -installation instructions please see the README [5]. - - -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. +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. -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. +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. -USAGE - command-line interface +(You may choose to use this package under the terms of either +licence, at your option.) -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 [6]. Other -ways to access the filesystem are planned: please see the -roadmap.txt [7] 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 [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 [7] shows the next -improvements that we plan to make and CREDITS [9] lists the names of -people who've contributed to the project. The wiki Dev page [10] -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 as well as by its p2p ancestor Mojo -Nation. It is primarily written in the Python programming language. +ACKNOWLEDGEMENTS -Tahoe is based on the Foolscap library [11] which provides a remote -object protocol inspired by the capability-secure "E" programming -language [12]. 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 [13]. -Computationally intensive operations are performed in native compiled -code, such as the "zfec" library for fast erasure coding (also -available separately: [14]). +Brian Warner +on behalf of the Tahoe-LAFS team +July 30, 2015 +San Francisco, California, USA -SPONSORSHIP -Tahoe is sponsored by Allmydata, Inc. [15], 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/wiki/Performance -[3] 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 -[4] http://allmydata.org/trac/tahoe/wiki/UseCases -[5] http://allmydata.org/trac/tahoe/browser/README?rev=1338 -[6] http://allmydata.org/trac/tahoe/browser/docs/webapi.txt?rev=1151 -[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/browser/CREDITS?rev=1270 -[10] http://allmydata.org/trac/tahoe/wiki/Dev -[11] http://twistedmatrix.com/trac/wiki/FoolsCap -[12] http://erights.org/ -[13] http://twistedmatrix.com/ -[14] http://allmydata.org/source/zfec/zfec/ -[15] 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