Commit 3c915d4d authored by Tails developers's avatar Tails developers

Merge remote branch 'origin/master'

parents 9140a6f6 e6d46dd4
It's still not clear exactly what we want to do with LAN traffic in
general (XXX: this should really have a ticket), but on the short run,
at least a minimal blacklist of known-bad traffic should be blocked:
* It was reported that NAT-PMP can be used to discover the LAN's
external IP-address on the Internet.
[[!tag todo/code]]
......@@ -35,3 +35,12 @@ Unsorted
[[libtorrent] socks proxy obedience](
Feedback from a user
I tried "apt-get install ctorrent" followed by "torify ctorrent torrentfile.torrent" while monitoring all communication with Wireshark. While ctorrent always generate new unique peer and key IDs each time the torrent is started, always report the same port, and always report IP=, do not attempt to discover external ip, and no proxy bypasses happens, I concluded it may be safe to use.
Besides that UDP does not work at all over Tor (DHT, uTP, UDP trackers etc...), which of course reduce the usefulness of a BitTorrent client in Tails, there is one real major problem I can see:
Each connection to a peer is going through its own Tor circuit. This means Tor ends up building about 100 circuits, using about half of them at any time. It also means it easily reach download speeds of 3 megabyte/second. One basically never get over 150 kilobytes/second through one single circuit (e.g. http downloads), so this DOES put a lot of load on the Tor network. Proposed solution would be to get all connections for the same torrent through the same circuit.
......@@ -3,9 +3,11 @@ suite would properly detect failure. Our manual erase memory test
procedure is a good example thereof: it checks that we *can* find the
pattern in memory if we skip the memory wipe step on purpose.
* Do we need an anti-test for non-IP packets in
* [[!taglink todo/code]] the anti-test of checking that, without
erasing memory, we can retrieve the known pattern. Just as we [[do
* [[!tag todo/discuss]] if we need an anti-test for non-IP packets in
`firewall_leaks.feature`? Does it even make sense? After all, so
far we've only cared about leaks to the Internet. What non-IP
packets can leak to the Internet?
[[!tag todo/discuss]]
......@@ -11,28 +11,9 @@ anonym after which the manual test can be removed:
* check that `memlockd` is running
# Discussion
# Tests that need fixing
The following test was tagged (in commit 3391f56) in an unexplained way:
* Testing that the needed files are really mapped in memory, and the
erasing process actually works, involves a more complicated
process that is worth [[a dedicated page|contribute/release_process/test/erase_memory_on_shutdown]].
`[needs-fix: erase_memory]` ([[todo/test_suite:_anti-tests]])
> What anti-tests are missing?
>> The anti-test of checking that, without erasing memory, we can
>> retrieve the known pattern. Just as we
>> [[do manually|contribute/test/erase_memory_on_shutdown]].
> The linked ticket mentions nothing relevant, but rather mentions
> that `erase_memory.feature` "is a good example thereof".
>> No. It says that our "**manual** erase memory test procedure is
>> a good example thereof". --intrigeri
[[!tag todo/discuss]]
See [[todo/test_suite:_anti_tests]].
# Related tickets
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment