-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ===================================================== Tahoe-LAFS Weekly News, issue number 36, July 16 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 ============== b It's very well designed, a pleasure to see such a system.b b Geoffroy Couprie <geo.couprie@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 b& 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 B5TP (`#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@antagonism.org`_ *b submission deadline: Friday night.* .. _marlowe@antagonism.org: mailto:marlowe@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----- _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE