[tahoe-dev] TWN 31

Sat May 19 17:54:48 UTC 2012

Welcome to the Tahoe-LAFS Weekly News (TWN).  Tahoe-LAFS_ is a secure,
distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_.
If you would like to view the "new and improved" TWN, complete with pictures;
please take a `look`_.

.. _Tahoe-LAFS: https://tahoe-lafs.org
.. _View TWN on the web: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews
.. _subscribe to TWN: https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news
.. _look: https://tahoe-lafs.org/~marlowe/TWN31.html

Announcement and News
=====================

Roadmaps Announced
- ------------------
David-Sarah |davidsarah| `announced the roadmaps`_ for 1.9.2, 1.10.0 and
1.11.0.

1.9.2 will be a bugfix release.  Its focus will be fixing regressions in
mutable file support.  Although developers resolved several of the bugs,
further testing and review is necessary.  1.9.2 will be released from
the darcs branch and will hopefully release at the end of May.

1.10.0 will be released via git.  It will include Brian Warner's
|brian| introducer improvements, including Ed25519-signed
announcements.  This will allow for multiple introducers and accounting.
Also this release will see a "move" operation added to the web
interface.

1.11.0's features have not been set in stone.  However, they may include

 * improvements to share placement to meet the servers-of-happiness
   criterion in more cases;
 * extending servers-of-happiness to mutable files;
 * some form of accounting;
 * a read-only mode for Tahoe gateways;
 * support for AES+XSalsa encryption, which would remain secure even if
   a flaw were discovered in either one of its constituent ciphers,
   including if there were a timing attack against the AES implementation;
 * a 'tahoe mount' command that simplifies mounting a Tahoe filesystem
   via sshfs;
 * merging the S3 backend support (and possibly other cloud service
 * support) developed by Least Authority Enterprises;
 * extending the drop-upload feature to Windows;
 * merging the patches for Tor and I2P into the main release.

.. _`announced the roadmaps`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-May/007340.html

Redundant Array of Independent Clouds
- -------------------------------------

Diego "sickness" Righi |sickness| created a `Redundant Array of
Independent Clouds`_ (RAIC).  Cloud services while simple and
attractive, experience three major issues.  One, what happens if they
fail and lose your files?  Two, how do they prevent someone from gaining
unauthorized access to your files?  Three, what recourse do you have to
your files if the service stops providing access (i.e. bankrupt,
government shutdown).  Through the use of Tahoe-LAFS, sickness is able
to overcome these issues with three large benefits:

"1) My files are encrypted BEFORE being stored on my local disk and
BEFORE being sent to the remote cloud provider, so whoever stoles this
local workstation or manages to hack the remote cloud servers will not
get access to my files
2) I can configure a zfec factor of 3:6 so in the event that 3 cloud
providers should lose my files, or close and go out of business, I'll
still be able of recover my files from the remaining 3 cloud providers
that still work, what we have here is effectively a RAIC (redundant
array of inexpensive clouds) :)
3) I could instead configure a zfec factor of 5:6 so I can maximize the
space that I have striping across multiple free "few Gb" accounts like
in a RAID5 pool of disks, effectively building a cheap and inexpensive
big cloud disk, and still being able to recover my files in the event
that one cloud provider fails." [`0`_]

Least Authority Enterprise (LAE) |LAE| is also working on RAIC through
the use of cloud services which support an HTTP API. Sickness'
implementation works instead by letting the cloud service client sync
the directory in which Tahoe-LAFS stores the encrypted shares.

Sickness's approach has the advantage that it can sync with services
which do not provide an API. However, this implementation depends on the
correctness and availability of the syncing implementation. For example,
if the Dropbox process dies, the shares are still fine on your local
disk, but they are no longer being synched.

.. _`Redundant Array of Independent Clouds`:
   http://www.sickness.it/crazycloudexperiment.txt
.. _`0`: http://www.sickness.it/crazycloudexperiment.txt
.. |LAE| image:: LAE.png
   :height: 35
   :alt: Least Authority Enterprises
   :target: http://leastauthority.com

Glowing Quotes
==============

“At Virginia Tech Linux and Unix Users Group, we have a working
Tahoe-LAFS deployment of about 9-14 nodes. It's incredibly reliable.
It's based at Virginia Tech, with the introducer on a university-hosted
servers, plus a few nodes in the dorms. One day, VT disappeared from the
net. They had a problem with one of their uplinks and all their edge
routers stopped routing. The introducer and about half the nodes on the
grid were down for maybe an hour. At no point was any data stored on the
grid inaccessible to any of the nodes, because all the ones outside
could talk to the ones outside, and the ones inside could talk to the
ones inside.” — Marcus Wanner |marcusw|

Tahoe-LAFS on Twitter
=====================

With #I2P in 1.11! RT @zooko Plans for Tahoe-LAFS v1.9.2, v1.10, and
v1.11: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-May/007340.html
Join us! ☺ [`1`_]

.. _`1`: https://twitter.com/#!/i2p/status/202384723773882368

- From the tahoe-dev Mailing List
===============================

End of Support for Python 2.4
- -----------------------------

Tahoe-LAFS is at long last going to `stop being backwards-compatible
with Python 2.4`_. The plan is for the Tahoe-LAFS v1.9.2 release to be
the last one that works with Python 2.4, and starting with the v1.10
release it will require Python 2.5, 2.6, or 2.7.

Authenticated Data Structures
- -----------------------------

Andrew Miller |amiller| wrote a dense technical post about a concept
called "`Authenticated Data Structures`_", which unifies concepts from
Bitcoin, proofs-of-work, and Tahoe-LAFS append-only files or add-only
sets. At press time nobody else had understood it well enough to write a
reply.

New User Documentation
- ----------------------

Michael Rogers suggested a `few user-experience and documentation
issues`_ experienced by a new user trying to install Tahoe-LAFS for the
first time. David-Sarah responded by creating trac tickets to track
progress on Michael's issues. There was a pony involved.

Use the Source
- --------------

A new user named Han Zheng asked how to get started `studying
Tahoe-LAFS's source code`_. Zooko suggested starting by reading the
server implementation. Since servers aren't allowed to know anything
about the plaintext in Tahoe-LAFS, they are dumber and easier to learn
than the other components.

.. _`stop being backwards-compatible with Python 2.4`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-May/007345.html
.. _`Authenticated Data Structures`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-May/007331.html
.. _`few user-experience and documentation issues`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-May/007329.html
.. _`studying Tahoe-LAFS's source code`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-May/007337.html

Patches Needing Review of the Week
==================================

There is two (2) ticket still needing review for 1.9.2:

* `#1740`_: new zope.interface deprecation warning about "implements()"
* `#1115`_: add servers-of-happiness to reports (post-repair says 10
  hosts have good shares but there only 4 hosts)

There are three (3) ticket still needing review for 1.10.0:

* `#1693`: flogtool doesn't get provided
* `#1658`: drop support for Python < 2.6
* `#1240`_: add functional test of ResponseCache in favour of
  MDMFSlotReadProxy's cache

There are three (3) tickets still needing review of 1.11.0:

* `#1265`_: New Visualizer is insufficiently labelled/documented (plus
  layout problem)
* `#1382`_: immutable peer selection refactoring and enhancements
* `#1569`_: rerecord and review pluggable backends for landing on trunk

.. _`#1740`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1740
.. _`#1115`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1115
.. _`#1693`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1693
.. _`#1658`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1658
.. _`#1240`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1240
.. _`#1265`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265
.. _`#1382`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382
.. _`#1569`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1569

- ----

*The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS*
*Software Foundation, President and Treasurer: Peter Secor* |peter|
*. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn*
*, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_
*. Send your news stories to* `marlowe at antagonism.org`_ *— submission
deadline: Friday night.*

.. _marlowe at antagonism.org: mailto:marlowe at antagonism.org
.. |zooko| image:: zooko.png
   :height: 35
   :alt: zooko
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs
.. |peter| image:: psecor.jpg
   :height: 35
   :alt: peter
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs
.. |marlowe| image:: marlowe-x75-bw.jpg
   :height: 35
   :alt: marlowe
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs
.. |davidsarah| image:: davidsarah_bw.png
   :height: 35
   :alt: davidsarah
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wikiAboutUs
.. |brian| image:: warner.png
   :height: 35
   :alt: brian
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs
.. |marcusw| image:: marcus.png
   :height: 35
   :alt: marcusw
.. |sickness| image:: sickness.jpg
   :height: 35
   :alt: sickness
.. |amiller| image:: amiller_grey.png
   :height: 35
   :alt: amiller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPt95jAAoJEAT4nRyi0elyOD8P/0Ny0WKMHIurxkTd99hlu9US
/2Cd1NkCaeSJYxetCMFCHE0bYbaduMJwD6GhJVxJgGmQZUh3xHP475EKOhePvU/a
eNpiepiKXxb5jwWGM/l6w3NyGIXj4aH0pm5/o/Jq+LzxyFhKnSUvPrMZvF3z/Mor
2GSZ3UyPYd5Aj63FXhJap9FAj0CIzY3r/TXZ61wI/FELeicH/0rHXhiMUc/Wz5Nm
xtWAq8g6ckb3cUd660uZ/BAZIvubTTqygLtp+GFwZ7TQtuJU2sENU+EyfnHod1jV
LrSlxBjBo9qiQXMbSfvWnpUtaJWM9p50vo7uNkebhIqgiIxlvCytJibNk+MLJ3yA
3/7PCu64sJJWJomOrZh9keMUpuc/kHu/j/pIt0ecbSB5Ui0EWc7AAxz9E/PX39N0
mwmWWs3RQ9kIyvagsdD4j0wDy5vjriWLs/JC2Ubj+8roSwUY+QrcByAK2mTi1v09
MzSXbZjvKMhX4Vh+ptm/Ft4MwlK1QBG8fkJPOBvwOq1qJ7KqZ1q6/Lsiw7JvzW7N
XtG6uawBZkuCRNj9ITCufyK5BPJKCk33d2xIEJo8opXF1bM1Isf9NM78zVpa/pWS
+K3+srt/6mTcazccmsmaG3Sw8injcHusUSaz3T4jV4gILs15p/MAmWMvKgaATydD
qpsFt3sENrZXeqy9aDxz
=xYLP
-----END PGP SIGNATURE-----