Ticket #1192: doc-patch-1192.dpatch

Sat Sep  4 15:35:25 CEST 2010  francois@ctrlaltdel.ch
  * docs/frontends/FTP-and-SFTP.txt: warn users about connecting to the SFTP server remotely. Fix #1192

New patches:

[docs/frontends/FTP-and-SFTP.txt: warn users about connecting to the SFTP server remotely. Fix #1192
francois@ctrlaltdel.ch**20100904133525
 Ignore-this: 38c8b1e423a3c8645185117a0fec9d7e
] hunk ./docs/frontends/FTP-and-SFTP.txt 107
 will complain if a subsequent connection uses a different key. This reduces
 the opportunity for man-in-the-middle attacks to just the first connection.
 
+Exercise caution when connecting to the SFTP server remotely. The AES
+implementation used by the SFTP code does not have defenses against
+timing attacks. The code for encrypting the SFTP connection was not
+written by the Tahoe-LAFS team, and we have not reviewed it as carefully
+as we have reviewed the code for encrypting files and directories in
+Tahoe-LAFS itself. If you can run the SFTP server (which is provided by
+the Tahoe-LAFS gateway) on the same host as your SFTP client then you
+would be safe from any problem with the SFTP connection security.
+
 You will use directives in the tahoe.cfg file to tell the SFTP code where to
 find these keys. To create one, use the ssh-keygen tool (which comes with the
 standard openssh client distribution):

Context:

[tests: assign the storage servers to a fixed order which triggers a bug in new downloader every time this test is run (formerly this test would detect the bug in new-downloader only sporadically)
zooko@zooko.com**20100904041515
 Ignore-this: 33155dcc03e84217ec5541addd3a16fc
 If you are investigating the bug in new-downloader, one way to investigate might be to change this ordering to a different fixed order (e.g. rotate by 4 instead of rotate by 5) and observe how the behavior of new-downloader differs in that case.
] 
[TAG allmydata-tahoe-1.8.0c3
zooko@zooko.com**20100902212140
 Ignore-this: e4550de37f57e5c1a591e549a104565d
] 
[docs: update relnotes.txt for v1.8.0c3
zooko@zooko.com**20100902212111
 Ignore-this: 7211f79f4c388c9e8ff0d05f22eb3ba2
] 
[download status: fix bug from me committing the wrong one of François's #1172 patches, fixes #1172
zooko@zooko.com**20100902161541
 Ignore-this: aeaa3befa632dbc7216686bb67a9695f
] 
[DownloadStatus: show active immutable downloads in Active Operations, Fix #1172
francois@ctrlaltdel.ch**20100902101728
 Ignore-this: 47d2b214bbf6e4713890f0ba4d4beecf
] 
[tests: bump up the allowed number of reads
zooko@zooko.com**20100902053801
 Ignore-this: 9450a720c9c5f51d63454029673cca16
 Kyle's OpenBSD buildslave used 41 reads when doing this test. The fact that I'm blindly bumping this number up to match the observed behavior probably means this isn't a good criterion to be testing for anyway. But perhaps someone else (Brian) could investigate why that run on Kyle's OpenBSD box took four more reads than we expected, and whether the fact that it took 41 reads to do this operation is indicative of an actual problem.
] 
[SegmentFetcher: use new diversity-seeking share-selection algorithm, and
"Brian Warner <warner@lothar.com>"**20100901013702
 deliver all shares at once instead of feeding them out one-at-a-time.
 
 Also fix distribution of real-number-of-segments information: now all
 CommonShares (not just the ones used for the first segment) get a
 correctly-sized hashtree. Previously, the late ones might not, which would
 make them crash and get dropped (causing the download to fail if the initial
 set were insufficient, perhaps because one of their servers went away).
 
 Update tests, add some TODO notes, improve variable names and comments.
 Improve logging: add logparents, set more appropriate levels.
 
] 
[Share: drop received data after each block finishes. Quick fix for the #1170 spans.py complexity bug.
"Brian Warner <warner@lothar.com>"**20100901013558] 
[docs: a couple of small edits to CREDITS and how_to_make_a_tahoe-lafs_release.txt
zooko@zooko.com**20100829222758
 Ignore-this: cfdb414f86dfd581b5f1d4d94231b85c
] 
[add simulator to explore the trade-offs for hashed-based digital signatures
zooko@zooko.com**20100819030630
 Ignore-this: 284e6d8b4140d2ecd9a4b14247d0816f
] 
[_auto_deps.py: change pycrypto version requirement to avoid https://bugs.launchpad.net/pycrypto/+bug/620253
david-sarah@jacaranda.org**20100829230038
 Ignore-this: e58f98ef262444067fc4b31fad23e40b
] 
[docs: update NEWS a bit about New-Downloader
zooko@zooko.com**20100819021446
 Ignore-this: 31a6e2fb0a6e3d19f73481e99070da7a
] 
[misc: add benchmarking tool for spans
zooko@zooko.com**20100819021420
 Ignore-this: 569327a1908a07e5fb634526bed515b2
] 
[web: refactor rate computation, fixes #1166
francois@ctrlaltdel.ch**20100815141933
 Ignore-this: d25491858e137894142eaa67c75b0439
] 
[docs: doc of the download status page
zooko@zooko.com**20100814054117
 Ignore-this: a82ec33da3c39a7c0d47a7a6b5f81bbb
 ref: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1169#comment:1
] 
[docs: NEWS: edit English usage, remove ticket numbers for regressions vs. 1.7.1 that were fixed again before 1.8.0c2
zooko@zooko.com**20100811071758
 Ignore-this: 993f5a1e6a9535f5b7a0bd77b93b66d0
] 
[docs: NEWS: more detail about new-downloader
zooko@zooko.com**20100811071303
 Ignore-this: 9f07da4dce9d794ce165aae287f29a1e
] 
[TAG allmydata-tahoe-1.8.0c2
david-sarah@jacaranda.org**20100810073847
 Ignore-this: c37f732b0e45f9ebfdc2f29c0899aeec
] 
Patch bundle hash:
e14f2a25c5901fe50e6a168ef69e78850815e5b4