TWN Hits Issue #25

With much delay, TWN hits the 25 issue milestone. I had greatly hoped we would reach this milestone much earlier. Unfortunately though work and personal life sometimes got in the way. Even after 25 issues, working on TWN every Friday is one of my favorite activities. I would like to thank the development team at Tahoe-LAFS for giving me the opportunity to contribute this way. Thank you very much.

Not one to sit still, present outage excluded, we are working on more ways for you to be able to get your TWN fix. Look for them to be coming in the near future.

David-Sarah Named Release Manager for Next Release

David-Sarah is the release manager for Tahoe-LAFS' next release. They were previously the release manager for 1.7. Look for their announcement on whether it will a bugfix-oriented 1.9.2 or a shiny new 1.10.0. Among the many other decisions for them, will be whether to continue using darcs and git or finally cut over to git (#1644).

Boulder Hackfest

Zooko hosted a Tahoe-LAFS hackfest in lovely Boulder, CO. Lots of work got done and I wish I could have attended. David-Sarah did a tremendous job in cleaning up the Trac tickets. This is very much appreciated. Andrew Miller wrote a unit test for #641 to make "tahoe backup" follow a limited number of symlinks. Peter Le Bek did some work on the wiki and fixed #1668. Brian fixed #1689. John Dougherty posted his first review. Lastly, I started reviewing documentation patches and resumed work on TWN. And that was just the first day. Thanks to Zooko for sponsoring the event and thanks to all those who attended and contributed.

pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958

pycryptopp 0.6.0.1206569328141510525648634803928199668821045408958 was released. Aside from having one of the coolest version numbers in existance, pycryptop is "a python wrapper around a few algorithms from the Crypto++ and python-Ed25519 libraries." [0]. Included in this release were the following fixes/features:

• src/pycryptopp/_version.py: release pycryptopp-0.6.0
• add Ed25519 signatures (#75)
• add XSalsa20 cipher (#40)
• switch from darcs to git for revision control
• pycryptopp version numbers now include a decimal encoding of …
• reorganize the source tree and the version number generation
• aesmodule.cpp: validate size of IV and throw exception if it is not 16 (#70)
• fixed compile errors with gcc-4.7.0 (#78)
• fixed compile errors concerning "CryptoPP::g_nullNameValuePairs" (#77)
• suppress warnings from valgrind with new OpenSSL 1.0.1 on Fedora (#82)
• raise Python exception instead of uncaught C++ exception (resulting in abort) when deserializing malformed RSA keys (#83)

Signed-Introducer Announcements

As a result of the new pycryptopp, signed-introducer code has landed (#466). For users, this means:

• tahoe now depends upon the new pycryptopp: next time you update, you'll need to do 'setup.py build' so it will pick up 0.6.0
• the first time your node wakes up with the new code, it will create a NODEDIR/private/server.privkey file, containing the new Ed25519 private signing key. This is a binary file, not meant for copy/paste or human interaction.
• server IDs are changing. The old (foolscap-based) IDs look like "rkybwv7hpuwpnyqhwjz43v727orr7fqd". Once everything is upgraded, the Welcome page will show new server IDs that look like "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". (the old ones are a SHA1 hash of the tub's public SSL certificate, the new ones are an Ed25519 public verifying key) [1]

Even more exciting is what this means for the future. Signed-introducer announcements open the door to a good many things:

• Introducer announcements are now extensible dictionaries, instead of fixed-size tuples. This allows servers to cleanly advertise new services, and include additional metadata like how much space they have available. This will be used by the upcoming Accounting work to advertise an alternate storage-server object from which per-account connections can be obtained. #666
• Announcements are signed, which means the Introducer doesn't get to modify the metadata, reducing its authority a little bit. This gets us one step closer to having a distributed introduction mechanism (the signed announcements can simply be flooded, without worrying about what the other nodes might do to them in transit). #68
• Server nodes are known by their Ed25519 public verifying key, rather than by their Foolscap SSL TubID. This enables secure non-SSL messaging (sign a request instead of sending unsigned requests over a validated-SSL connection), so we can switch from Foolscap to e.g. HTTP for share transport, which should make the Tahoe protocol easier to port to other languages (Foolscap offers more features than we really need, and its need to check the SSL certificate is an implementation hassle). #510
• Clients can securely reference a server by its pubkey, which will be the basis for explicit "which servers am I willing to use" configuration. #467, #295 [2]