[tahoe-lafs-weekly-news] TWN 36

Tue Jul 17 01:42:03 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/TWN36.html

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

1.9.2 Released
- --------------

David-Sarah |davidsarah| `announced the release of Tahoe-LAFS 1.9.2`_.
Tahoe-LAFS 1.9.2 is primarily a bugfix release which fixes regressions
in mutable file support.  Take a look at `NEWS`_ to see all the fixes.

.. |davidsarah| image:: davidsarah_bw.png
   :height: 35
   :alt: davidsarah
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wikiAboutUs

.. _`announced the release of Tahoe-LAFS 1.9.2`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-July/007527.html
.. _`NEWS`: https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst

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

“It's very well designed, a pleasure to see such a system.” — Geoffroy
Couprie <geo.couprie at gmail.com>

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

Just heard #tahoe-lafs mentioned in a #HOPE9 lightning talk, Crypto
Tools for Distributed Social Media [`0`_]

Setting up Tahoe-LAFS over I2P. This is … interesting! [`1`_]

@KimDotcom checkout tahoe-lafs by @zooko [`2`_]

.. _`0`: https://twitter.com/antagonismorg/status/224565359431270400
.. _`1`: https://twitter.com/UnOrigMoniker/status/224468401119178753
.. _`2`: https://twitter.com/sj_mackenzie/status/223697328404578304

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

On the limits of the use cases for authenticated encryption
- -----------------------------------------------------------

Zooko |zooko| `announced` Tahoe-LAFS's use case was discussed at
`Directions in Authenticated Ciphers workshop`.  Zooko decided
"authenticated encryption" is not useless for Tahoe-LAFS use cases.  He
believes Tahoe-LAFS needs "public key authenticated encryption" instead
of "symmetric key".

.. |zooko| image:: zooko.png
   :height: 35
   :alt: zooko
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs

.. _`announced`:
   https://tahoe-lafs.org/pipermail/tahoe-dev/2012-July/007568.html
.. _`Directions in Authenticated Ciphers workshop`:
   http://hyperelliptic.org/DIAC/

p2p or client/server (Introducers to gossip)
- --------------------------------------------

`Discussion continues` on the introducers to gossip thread.  The
discussion centers on whether to continue with the client/server
architecture or move to a p2p style architecture.  Users of
client/server most likely want:

Which services? Each node operates, by default, only the services
that the operator manually configured it to run. Even better you can
install the software sufficient to run a specific kind of node, e.g. a
storage server, without installing the software that would let it run
other servers, such as introducers or storage clients (`#1694`_).

Which IP addresses? Nodes do not automatically detect their own IP
addresses, but instead use only the IP address that their sysadmin
manually told them to use. This is especially important for tor and
i2p people where any auto-discovered IP address threatens the user's
safety (`#517`_).

Which connections? You try to establish the prescribed TCP
connection(s) to your server. If that fails, you log/announce failure.
In the future you might even be able to configure it to run
exclusively over HTTP(S) and then pass all of its connections through
your HTTP proxies and Web Services tools (`#510`_, `#1007`_).

(Although sysadmins may actually like the "try to connect to multiple
IP/DNS addresses at once" feature, if it is sufficiently
understandable and controllable to them. It would ease some headaches
provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for
example.)

How to handle NAT/firewall/inconveniently-behaving-router? If you
can't establish a TCP connection to your prescribed target, then
obviously you should not talk to it. Either some wise sysadmin doesn't
want you to (firewall) or some stupid sysadmin has screwed up the
network config and needs to fix it. In either case you should log
failure and give up immediately.

Reverse connections? Clients connect to servers. Servers do not
connect to clients, clients do not connect to other clients, and
servers do not connect to other servers (`#344`_). To violate this
principle means you will receive a visit from your keen-eyed sysadmin
who will want to know what the hell you are doing.

Users of the p2p model probably want:

Which services? Each node operates, by default, only the services
that the operator manually configured it to run. Even better you can
install the software sufficient to run a specific kind of node, e.g. a
storage server, without installing the software that would let it run
other servers, such as introducers or storage clients (`#1694`_).

Which IP addresses? Nodes do not automatically detect their own IP
addresses, but instead use only the IP address that their sysadmin
manually told them to use. This is especially important for tor and
i2p people where any auto-discovered IP address threatens the user's
safety (`#517`_).

Which connections? You try to establish the prescribed TCP
connection(s) to your server. If that fails, you log/announce failure.
In the future you might even be able to configure it to run
exclusively over HTTP(S) and then pass all of its connections through
your HTTP proxies and Web Services tools (`#510`_, `#1007`_).

(Although sysadmins may actually like the "try to connect to multiple
IP/DNS addresses at once" feature, if it is sufficiently
understandable and controllable to them. It would ease some headaches
provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for
example.)

How to handle NAT/firewall/inconveniently-behaving-router? If you
can't establish a TCP connection to your prescribed target, then
obviously you should not talk to it. Either some wise sysadmin doesn't
want you to (firewall) or some stupid sysadmin has screwed up the
network config and needs to fix it. In either case you should log
failure and give up immediately.

Reverse connections? Clients connect to servers. Servers do not
connect to clients, clients do not connect to other clients, and
servers do not connect to other servers (`#344`_). To violate this
principle means you will receive a visit from your keen-eyed sysadmin
who will want to know what the hell you are doing .

Users of a p2p model probably want:

Which services? Each node operates, by default, multiple services --
storage server, storage client == web gateway, introducer/gossiper,
and in the future other services like relay server (to help get around
incomplete connectivity of the underlying network -- `#445`_).

Which IP addresses? Nodes automatically detect their own IP
addresses, such as by inspecting the output of "/sbin/ifconfig" or
"route.exe", or opening a TCP connection to some helpful STUNT/ICE
server and asking that server what IP address your packets appear to
be coming from (`#50`_).

Which connections? Nodes advertise multiple IP addresses / DNS names
(possibly including those auto-discovered as above, plus any that were
manually entered by the user (`#754`_), plus 127.0.0.1 or any
globally-non-routeable IP addresses revealed by ifconfig, and possibly
in the future including indirection through a relay server), peers
attempt to connect to nodes on all advertised IP addresses / DNS names
in parallel, then use whichever connections succeeded.

How to handle NAT/firewall/inconveniently-behaving-router? Nodes
utilize the latest and greatest Romulan packet technology, such as
UPnP (`#49`_), "NAT hole punching" techniques (`#169`_) or even µTP
(`#1179`_) or relay service (`#445`_) to breeze through such
impediments as though they weren't even there.

Reverse connections? If a TCP connection is established from node A
to node B, then B can use that in the "reverse direction" to make
requests of A, just as well as A can use it to make requests of B.
This means that if A is behind a firewall which allows outgoing but
not incoming connections to be established, and A established an
outgoing connection to B, then B can use A as a server, but C, which
for some reason didn't get a connection from A, cannot use A as a
server. (`#1086`_)

.. _`#1694`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1694
.. _`#517`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/517
.. _`#510`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/510
.. _`#1007`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1007
.. _`#344`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/344
.. _`#445`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/445
.. _`#50`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/50
.. _`#754`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/754
.. _`#49`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/49
.. _`#169`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/169
.. _`#1179`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1179
.. _`#445`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/445
.. _`#1086`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1086

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

There are six (6) ticket still needing review for 1.10.0:

* `#1777`_: cleanups to tests and mutables for 1.10
* `#166`_: command line order is problematic
* `#937`_: 'tahoe run' doesn't work for an introducer node
* `#1539`_: stop putting pkg_resources.require() into .tac files
* `#1159`_: stop using .tac files: make it possible to change appname,
  Python package-directory name, perhaps other names
* `#1693`_: flogtool doesn't get automatically provided

There are two (2) 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

.. _`#1777`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1777
.. _`#166`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/166
.. _`#937`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/937
.. _`#1539`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1539
.. _`#1159`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159
.. _`#1693`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1693
.. _`#1265`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265
.. _`#1382`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382

- ----

*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
.. |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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQBMLoAAoJEAT4nRyi0elyvJEP/3SSUW/kBS5gxCm9kMFTbJaf
V9WIavIjmdOVCZ2WRsoV6X3+Z3oTM1JeKMM/7N+w3ACYLUA5d8GV1FkqHar3zPbD
pwBLZKeNg+YgcCXfygFZTJl4nsde6JsRUDCzHcXXYL3uSnDgrPt+RfmStkSLs7Ce
dcgKSOT/w+cTqrNPwaHmkC6xGMGn8O4IukvJAIeqhHlm5+7d43vfnRXfxAT8hgcG
GXz23ZI3lTaxmSA3H3PhMwxsAGUTR28Mpv5F5YgGqHTQbGODwqwPBcGS/87Gi4U7
0a3YsYBzzkCVm3kTGdhmlxd2WXu5ffaaglLonOW6J7up04+vaB4XAp3BJ5Y/Cmmr
YvZBWIw6r8PMvrFQ9LRN74EvYnYSDDqqxBXNRNcefZyuyojvcsZeLMP3zt4eC8lt
pbH5r871zrSa3+X/cQ2iW4qSZwIPMOVODbWkesa2usQyWmLWzoLh/mjdW2xs/8mN
nayWsSH615hv0kzi61giqesNyRkXTYz6Ubmzu5d3UQPPu7XxTlrnWywJ631iKuev
++JJ9Go9zwOqfu92OpmH5qS3GtF7mQ1bk4ZGyH1c16jSQWcmZZbd/CaR1+CzwPM0
VCCSkfPHmT5vPCBkvEk6ac89yiS8c8nww0h3GlFKLyr6Dz5/wL1ry6bvxDeM2gJv
wBCaAbFXUMNrJah8sdB4
=/Nj8
-----END PGP SIGNATURE-----