Commit graph

11 commits

Author SHA1 Message Date
gdt
f0875e02d7 tahoe-lafs: Update to 1.15.0
Release 1.15.0 (2020-10-13)
'''''''''''''''''''''''''''

Features
--------

- PyPy is now a supported platform. (`#1792 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1792>`_)
- allmydata.testing.web, a new module, now offers a supported Python API for testing Tahoe-LAFS web API clients. (`#3317 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3317>`_)


Dependency/Installation Changes
-------------------------------

- Tahoe-LAFS now supports CentOS 8 and no longer supports CentOS 7. (`#3296 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3296>`_)
- Tahoe-LAFS now supports Ubuntu 20.04. (`#3328 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3328>`_)


Removed Features
----------------

- The Magic Folder frontend has been split out into a stand-alone project.  The functionality is no longer part of Tahoe-LAFS itself.  Learn more at <https://github.com/LeastAuthority/magic-folder>. (`#3284 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3284>`_)
- Slackware 14.2 is no longer a Tahoe-LAFS supported platform. (`#3323 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3323>`_)
2021-03-18 17:57:08 +00:00
gdt
529e70f77e tahoe-lafs: Update to 1.13.0
Release 1.13.0 (05-August-2018)
'''''''''''''''''''''''''''''''

New Features
------------

The ``tahoe list-aliases`` command gained the ``--readonly-uri``
option in `PR400`_, which lists read-only capabilities (the default
shows read/write capabilities if available). This command also gained
a ``--json`` option in `PR452`_, providing machine-readable output.

A new command ``tahoe status`` is added, showing some statistics and
currently active operations (similar to the ``/status`` page in the
Web UI). See also `PR502`_.

Immutable uploads now use the "servers of happiness" algorithm for
uploading shares. This means better placement of shares on available
servers. See `PR416`_.

To join a new client to a grid, the command ``tahoe invite`` was
added. This uses `magic wormhole`_ to connect two computers and
exchange the required information to start the client. The "client
side" of this command is the also new option ``tahoe
create-client --join=``. Together, this provides a way to provision a
new client without having to securely transmit the fURL and other
details. `PR418`_

``tahoe backup`` now reports progress. `PR474`_

The ``tub.port=`` option can now accept ``listen:i2p`` or
``listen:tor`` options to use popular anonymity networks with storage
servers. See `PR437`_

The place where storage servers put shares (the "storage path") is now
configurable (`PR472`_).

A PyInstaller-based build is now available (`PR421`_). A "Docker
compose" setup for development purposes is now available (`PR445`_).

There is now a recommended workflow for Zcash-based donations to support
storage server operators (`PR506`_).


Web UI Changes
--------------

We set the "Referrer-Policy: no-referrer" header on all requests. The
Welcome page now understands the JSON option (`PR430`_) and OPTIONS
requests are handled (`PR447`_).


Magic Folder Changes
--------------------

Multiple magic-folders in a single Tahoe client are now
supported. Bugs with ``.backup`` files have been fixed, meaning
spurious ``.backup`` files will be produced less often (`PR448`_,
`PR475`_). Handling of default umask on new magic-folder files is
fixed in `PR458`_. The user mtime value is now correctly preserved
(`PR457`_).

A bug in ``tahoe magic-folder status`` causing active operations to
sometimes not show up is fixed (`PR461`_). If a directory is missing,
it is created (`PR492`_).
2021-03-18 17:32:25 +00:00
riastradh
a9d32ffb17 Update filesystems/tahoe-lafs to 1.12.1. 2017-01-28 09:09:50 +00:00
wiz
2b684e24c1 Update to 1.10.2:
Release 1.10.2 (2015-07-30)
'''''''''''''''''''''''''''

Packaging Changes
-----------------

This release no longer requires the ``mock`` library (which was previously
used in the unit test suite). Shortly after the Tahoe-LAFS 1.10.1 release, a
new version of ``mock`` was released (1.1.0) that proved to be incompatible
with Tahoe's fork of setuptools, preventing Tahoe-1.10.1 from building at
all. `#2465`_

The ``tahoe --version`` output is now less likely to include scary diagnostic
warnings that look deceptively like stack traces. `#2436`_

The pyasn1 requirement was increased to >= 0.1.8.

.. _`#2465`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2465
.. _`#2436`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2436

Other Fixes
-----------

A WebAPI ``GET`` would sometimes hang when using the HTTP Range header to
read just part of the file. `#2459`_

Using ``tahoe cp`` to copy two different files of the same name into the same
target directory now raises an error, rather than silently overwriting one of
them. `#2447`_

All tickets closed in this release: 2328 2436 2446 2447 2459 2460 2461 2462
2465 2470.

.. _`#2459`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2459
.. _`#2447`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2447
2015-08-14 20:37:43 +00:00
wiz
6875222e33 Update to 1.10.1:
Release 1.10.1 (2015-06-15)
'''''''''''''''''''''''''''

User Interface / Configuration Changes
--------------------------------------

The "``tahoe cp``" CLI command's ``--recursive`` option is now more predictable,
but behaves slightly differently than before. See below for details. Tickets
`#712`_, `#2329`_.

The SFTP server can now use public-key authentication (instead of only
password-based auth). Public keys are configured through an "account file",
just like passwords. See docs/frontends/FTP-and-SFTP for examples of the
format. `#1411`_

The Tahoe node can now be configured to disable automatic IP-address
detection. Using "AUTO" in tahoe.cfg [node]tub.location= (which is now the
default) triggers autodetection. Omit "AUTO" to disable autodetection. "AUTO"
can be combined with static addresses to e.g. use both a stable
UPnP-configured tunneled address and a DHCP-assigned dynamic (local subnet
only) address. See `configuration.rst`_ for details. `#754`_

The web-based user interface ("WUI") Directory and Welcome pages have been
redesigned, with improved CSS for narrow windows and more-accessible icons
(using distinctive shapes instead of just colors). `#1931`_ `#1961`_ `#1966`_
`#1972`_ `#1901`_

.. _`#712`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/712
.. _`#754`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/754
.. _`#1411`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1411
.. _`#1901`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1901
.. _`#1931`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1931
.. _`#1961`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1961
.. _`#1966`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1966
.. _`#1972`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1972
.. _`#2329`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2329
.. _`configuration.rst`: docs/configuration.rst

"tahoe cp" changes
------------------

The many ``cp``-like tools in the Unix world (POSIX ``/bin/cp``, the ``scp``
provided by SSH, ``rsync``) all behave slightly differently in unusual
circumstances, especially when copying whole directories into a target that
may or may not already exist. The most common difference is whether the user
is referring to the source directory as a whole, or to its contents. For
example, should "``cp -r foodir bardir``" create a new directory named
"``bardir/foodir``"? Or should it behave more like "``cp -r foodir/* bardir``"?
Some tools use the presence of a trailing slash to indicate which behavior
you want. Others ignore trailing slashes.

"``tahoe cp``" is no exception to having exceptional cases. This release fixes
some bad behavior and attempts to establish a consistent rationale for its
behavior. The new rule is:

- If the thing being copied is a directory, and it has a name (e.g. it's not
  a raw Tahoe-LAFS directorycap), then you are referring to the directory
  itself.
- If the thing being copied is an unnamed directory (e.g. raw dircap or
  alias), then you are referring to the contents.
- Trailing slashes do not affect the behavior of the copy (although putting
  a trailing slash on a file-like target is an error).
- The "``-r``" (``--recursive``) flag does not affect the behavior of the
  copy (although omitting ``-r`` when the source is a directory is an error).
- If the target refers to something that does not yet exist:
  - and if the source is a single file, then create a new file;
  - otherwise, create a directory.

There are two main cases where the behavior of Tahoe-LAFS v1.10.1 differs
from that of the previous v1.10.0 release:

- "``cp DIRCAP/file.txt ./local/missing``" , where "``./local``" is a
  directory but "``./local/missing``" does not exist. The implication is
  that you want Tahoe to create a new file named "``./local/missing``" and
  fill it with the contents of the Tahoe-side ``DIRCAP/file.txt``. In
  v1.10.0, a plain "``cp``" would do just this, but "``cp -r``" would do
  "``mkdir ./local/missing``" and then create a file named
  "``./local/missing/file.txt``". In v1.10.1, both "``cp``" and "``cp -r``"
  create a file named "``./local/missing``".
- "``cp -r PARENTCAP/dir ./local/missing``", where ``PARENTCAP/dir/``
  contains "``file.txt``", and again "``./local``" is a directory but
  "``./local/missing``" does not exist. In both v1.10.0 and v1.10.1, this
  first does "``mkdir ./local/missing``". In v1.10.0, it would then copy
  the contents of the source directory into the new directory, resulting
  in "``./local/missing/file.txt``". In v1.10.1, following the new rule
  of "a named directory source refers to the directory itself", the tool
  creates "``./local/missing/dir/file.txt``".

Compatibility and Dependency Updates
------------------------------------

Windows now requires Python 2.7. Unix/OS-X platforms can still use either
Python 2.6 or 2.7, however this is probably the last release that will
support 2.6 (it is no longer receiving security updates, and most OS
distributions have switched to 2.7). Tahoe-LAFS now has the following
dependencies:

- Twisted >= 13.0.0
- Nevow >= 0.11.1
- foolscap >= 0.8.0
- service-identity
- characteristic >= 14.0.0
- pyasn1 >= 0.1.4
- pyasn1-modules >= 0.0.5

On Windows, if pywin32 is not installed then the dependencies on Twisted
and Nevow become:

- Twisted >= 11.1.0, <= 12.1.0
- Nevow >= 0.9.33, <= 0.10

On all platforms, if pyOpenSSL >= 0.14 is installed, then it will be used,
but if not then only pyOpenSSL >= 0.13, <= 0.13.1 will be built when directly
invoking `setup.py build` or `setup.py install`.

We strongly advise OS packagers to take the option of making a tahoe-lafs
package depend on pyOpenSSL >= 0.14. In order for that to work, the following
additional Python dependencies are needed:

- cryptography
- cffi >= 0.8
- six >= 1.4.1
- enum34
- pycparser

as well as libffi (for Debian/Ubuntu, the name of the needed OS package is
`libffi6`).

Tahoe-LAFS is now compatible with Setuptools version 8 and Pip version 6 or
later, which should fix execution on Ubuntu 15.04 (it now tolerates PEP440
semantics in dependency specifications). `#2354`_ `#2242`_

Tahoe-LAFS now depends upon foolscap-0.8.0, which creates better private keys
and certificates than previous versions. To benefit from the improvements
(2048-bit RSA keys and SHA256-based certificates), you must re-generate your
Tahoe nodes (which changes their TubIDs and FURLs). `#2400`_

.. _`#2242`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2242
.. _`#2354`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2354
.. _`#2400`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2400

Packaging
---------

A preliminary OS-X package, named "``tahoe-lafs-VERSION-osx.pkg``", is now
being generated. It is a standard double-clickable installer, which creates
``/Applications/tahoe.app`` that embeds a complete runtime tree. However
launching the ``.app`` only brings up a notice on how to run tahoe from the
command line. A future release may turn this into a fully-fledged application
launcher. `#182`_ `#2393`_ `#2323`_

Preliminary Docker support was added. Tahoe container images may be available
on DockerHub. `PR#165`_ `#2419`_ `#2421`_

Old and obsolete Debian packaging tools have been removed. `#2282`_

.. _`#182`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/182
.. _`#2282`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2282
.. _`#2323`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2323
.. _`#2393`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2393
.. _`#2419`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2419
.. _`#2421`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2421
.. _`PR#165`: https://github.com/tahoe-lafs/tahoe-lafs/pull/165

Minor Changes
-------------

- Welcome page: add per-server "(space) Available" column. `#648`_
- check/deep-check learned to accept multiple location arguments. `#740`_
- Checker reports: remove needs-rebalancing, add count-happiness. `#1784`_ `#2105`_
- CLI ``--help``: cite (but don't list) global options on each command. `#2233`_
- Fix ftp "``ls``" to work with Twisted 15.0.0. `#2394`_

.. _`#648`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/648
.. _`#740`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/740
.. _`#1784`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1784
.. _`#2105`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2105
.. _`#2233`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2233
.. _`#2394`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2394

Roughly 75 tickets were closed in this release: 623 648 712 740 754 898 1146
1159 1336 1381 1411 1634 1674 1698 1707 1717 1737 1784 1800 1807 1842 1847
1901 1918 1953 1960 1961 1966 1969 1972 1974 1988 1992 2005 2008 2023 2027
2028 2034 2048 2067 2086 2105 2121 2128 2165 2193 2208 2209 2233 2235 2242
2245 2248 2249 2249 2280 2281 2282 2290 2305 2312 2323 2340 2354 2380 2393
2394 2398 2400 2415 2416 2417 2433. Another dozen were referenced but not
closed: 182 666 982 1064 1258 1531 1536 1742 1834 1931 1935 2286. Roughly 40
GitHub pull-requests were closed: 32 48 50 56 57 61 62 62 63 64 69 73 81 82
84 85 87 91 94 95 96 103 107 109 112 114 120 122 125 126 133 135 136 137 142
146 149 152 165.

For more information about any ticket, visit e.g.
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/754
2015-07-01 13:58:21 +00:00
gdt
bf4adc03e1 Update to:
Release 1.10.0 (2013-05-01)
'''''''''''''''''''''''''''

New Features
------------

- The Welcome page has been redesigned. This is a preview of the design style
  that is likely to be used in other parts of the WUI in future Tahoe-LAFS
  versions. (`#1713`_, `#1457`_, `#1735`_)
- A new extensible Introducer protocol has been added, as the basis for
  future improvements such as accounting. Compatibility with older nodes is
  not affected. When server, introducer, and client are all upgraded, the
  welcome page will show node IDs that start with "v0-" instead of the old
  tubid. See `<docs/nodekeys.rst>`__ for details. (`#466`_)
- The web-API has a new ``relink`` operation that supports directly moving
  files between directories. (`#1579`_)

Security Improvements
---------------------

- The ``introducer.furl`` for new Introducers is now unguessable. In previous
  releases, this FURL used a predictable swissnum, allowing a network
  eavesdropper who observes any node connecting to the Introducer to access
  the Introducer themselves, and thus use servers or offer storage service to
  clients (i.e. "join the grid"). In the new code, the only way to join a
  grid is to be told the ``introducer.furl`` by someone who already knew it.
  Note that pre-existing introducers are not changed. To force an introducer
  to generate a new FURL, delete the existing ``introducer.furl`` file and
  restart it. After doing this, the ``[client]introducer.furl`` setting of
  every client and server that should connect to that introducer must be
  updated. Note that other users of a shared machine may be able to read
  ``introducer.furl`` from your ``tahoe.cfg`` file unless you configure the
  file permissions to prevent them. (`#1802`_)
- Both ``introducer.furl`` and ``helper.furl`` are now censored from the
  Welcome page, to prevent users of your gateway from learning enough to
  create gateway nodes of their own.  For existing guessable introducer
  FURLs, the ``introducer`` swissnum is still displayed to show that a
  guessable FURL is in use. (`#860`_)

Command-line Syntax Changes
---------------------------

- Global options to ``tahoe``, such as ``-d``/``--node-directory``, must now
  come before rather than after the command name (for example,
  ``tahoe -d BASEDIR cp -r foo: bar:`` ). (`#166`_)

Notable Bugfixes
----------------

- In earlier versions, if a connection problem caused a download failure for
  an immutable file, subsequent attempts to download the same file could also
  fail. This is now fixed. (`#1679`_)
- Filenames in WUI directory pages are now displayed correctly when they
  contain characters that require HTML escaping. (`#1143`_)
- Non-ASCII node nicknames no longer cause WUI errors. (`#1298`_)
- Checking a LIT file using ``tahoe check`` no longer results in an
  exception. (`#1758`_)
- The SFTP frontend now works with recent versions of Twisted, rather than
  giving errors or warnings about use of ``IFinishableConsumer``. (`#1926`_,
  `#1564`_, `#1525`_)
- ``tahoe cp --verbose`` now counts the files being processed correctly.
  (`#1805`_, `#1783`_)
- Exceptions no longer trigger an unhelpful crash reporter on Ubuntu 12.04
  ("Precise") or later. (`#1746`_)
- The error message displayed when a CLI tool cannot connect to a gateway has
  been improved. (`#974`_)
- Other minor fixes: `#1781`_, `#1812`_, `#1915`_, `#1484`_, `#1525`_

Other Changes
-------------

- The provisioning/reliability pages were removed from the main client's web
  interface, and moved into a standalone web-based tool. Use the ``run.py``
  script in ``misc/operations_helpers/provisioning/`` to access them.
- Web clients can now cache (ETag) immutable directory pages. (`#443`_)
- `<docs/convergence_secret.rst>`__ was added to document the adminstration
  of convergence secrets. (`#1761`_)
2013-05-01 23:59:53 +00:00
gdt
d060bf6cb1 Update to 1.9.2.
Release 1.9.2 (2012-07-03)
----------------------------

Notable Bugfixes
''''''''''''''''

- Several regressions in support for reading (`#1636`_), writing/modifying
  (`#1670`_, `#1749`_), verifying (`#1628`_) and repairing (`#1655`_, `#1669`_,
  `#1676`_, `#1689`_) mutable files have been fixed.
- FTP can now list directories containing mutable files, although it
  still does not support reading or writing mutable files. (`#680`_)
- The FTP frontend would previously show Jan 1 1970 for all timestamps;
  now it shows the correct modification time of the directory entry.
  (`#1688`_)
- If a node is configured to report incidents to a log gatherer, but the
  gatherer is offline when some incidents occur, it would previously not
  "catch up" with those incidents as intended. (`#1725`_)
- OpenBSD 5 is now supported. (`#1584`_)
- The ``count-good-share-hosts`` field of file check results is now
  computed correctly. (`#1115`_)

Configuration/Behavior Changes
''''''''''''''''''''''''''''''

- The capability of the upload directory for the drop-upload frontend
  is now specified in the file ``private/drop_upload_dircap`` under
  the gateway's node directory, rather than in its ``tahoe.cfg``.
  (`#1593`_)
2012-07-07 00:34:18 +00:00
gdt
9814bbc915 Update to 1.9.0.
- The most significant new feature in this release is MDMF: "Medium-size
  Distributed Mutable Files". Unlike standard SDMF files, these provide
  efficient partial-access (reading and modifying small portions of the file
  instead of the whole thing). MDMF is opt-in (it is not yet the default
  format for mutable files), both to ensure compatibility with previous
  versions, and because the algorithm does not yet meet memory-usage goals.
  Enable it with ``--format=MDMF`` in the CLI (``tahoe put`` and ``tahoe
  mkdir``), or the "format" radioboxes in the web interface. See
  `<docs/specifications/mutable.rst>`_ for more details (`#393`_, `#1507`_)
- A "blacklist" feature allows blocking access to specific files through
  a particular gateway. See the "Access Blacklist" section of
  `<docs/configuration.rst>`_ for more details. (`#1425`_)
- A "drop-upload" feature has been added, which allows you to upload
  files to a Tahoe-LAFS directory just by writing them to a local
  directory. This feature is experimental and should not be relied on
  to store the only copy of valuable data. It is currently available
  only on Linux. See `<docs/frontends/drop-upload.rst>`_ for documentation.
  (`#1429`_)
- The timeline of immutable downloads can be viewed using a zoomable and
  pannable JavaScript-based visualization. This is accessed using the
  'timeline' link on the File Download Status page for the download, which
  can be reached from the Recent Uploads and Downloads page.
2011-11-09 00:30:12 +00:00
gdt
dffab4e884 Update to 1.8.2.
Packaging changes:
  Use gmake and test TEST_TARGET, so make test runs make check.
  Add dependency on py-sqlite2 for "tahoe backup".
  Add py-mock dependency because tests are now runnable by the user.
  Withdraw fixing of distfiles modes; this one is fine.

* Release 1.8.2 (2011-01-30)

** Compatibility and Dependencies

 - Tahoe is now compatible with Twisted-10.2 (released last month), as well
   as with earlier versions. The previous Tahoe-1.8.1 release failed to run
   against Twisted-10.2, raising an AttributeError on
   StreamServerEndpointService (#1286)
 - Tahoe now depends upon the "mock" testing library, and the foolscap
   dependency was raised to 0.6.1 . It no longer requires pywin32 (which
   was used only on windows). Future developers should note that
   reactor.spawnProcess and derivatives may no longer be used inside
   Tahoe code.

** Other Changes

 - the default reserved_space value for new storage nodes is 1 GB (#1208)
 - documentation is now in reStructuredText (.rst) format
 - "tahoe cp" should now handle non-ASCII filenames
 - the unmaintained Mac/Windows GUI applications have been removed (#1282)
 - tahoe processes should appear in top and ps as "tahoe", not "python",
   on some unix platforms. (#174)
 - "tahoe debug trial" can be used to run the test suite (#1296)
 - the SFTP frontend now reports unknown sizes as "0" instead of "?",
   to improve compatibility with clients like FileZilla (#1337)
 - "tahoe --version" should now report correct values in situations where
   1.8.1 might have been wrong (#1287)
2011-02-01 02:05:18 +00:00
gdt
e6af34d20f Update to 1.8.0.
* Release 1.8.0 (2010-09-23)

** New Features

 - A completely new downloader which improves performance and
   robustness of immutable-file downloads. It uses the fastest K
   servers to download the data in K-way parallel. It automatically
   fails over to alternate servers if servers fail in mid-download. It
   allows seeking to arbitrary locations in the file (the previous
   downloader which would only read the entire file sequentially from
   beginning to end). It minimizes unnecessary round trips and
   unnecessary bytes transferred to improve performance. It sends
   requests to fewer servers to reduce the load on servers (the
   previous one would send a small request to every server for every
   download) (#287, #288, #448, #798, #800, #990, #1170, #1191)

 - Non-ASCII command-line arguments and non-ASCII outputs now work on
   Windows. In addition, the command-line tool now works on 64-bit
   Windows. (#1074)

** Bugfixes and Improvements

 - Document and clean up the command-line options for specifying the
   node's base directory. (#188, #706, #715, #772, #1108)
 - The default node directory for Windows is ".tahoe" in the user's
   home directory, the same as on other platforms. (#890)
 - Fix a case in which full cap URIs could be logged. (#685, #1155)
 - Fix bug in WUI in Python 2.5 when the system clock is set back to
   1969. Now you can use Tahoe-LAFS with Python 2.5 and set your
   system clock to 1969 and still use the WUI. (#1055)
 - Many improvements in code organization, tests, logging,
   documentation, and packaging. (#983, #1074, #1108, #1127, #1129,
   #1131, #1166, #1175)
2010-09-24 18:20:59 +00:00
gdt
938e60f95e Import tahoe-lafs-1.7.1 as filesystems/tahoe-lafs.
Tahoe-LAFS is a Free Software/Open Source decentralized data store.
It distributes your filesystem across multiple servers, and even if
some of the servers fail or are taken over by an attacker, the entire
filesystem continues to work correctly and to preserve your privacy
and security.
2010-07-24 18:14:27 +00:00