Commit 8cd69273 authored by Tails developers's avatar Tails developers

Merge remote-tracking branch 'origin/master' into testing

parents 721ccb93 61a3b763
......@@ -161,6 +161,25 @@ Developers with write access to the repositories should instead:
We have a Gitweb available for [liveusb-creator](
and a [[release process|release_process/liveusb-creator]].
<a id="sikuli-wrapper"></a>
sikuli-wrapper is a tiny interface that gives access to
[Sikuli]('s features over a TCP port, for use in any
programming language.
Anyone can check it out like this:
git clone git://
Developers with write access to the repositories should instead:
git clone [email protected]:sikuli-wrapper.git
We have a web interface available for [sikuli-wrapper](
<a id="tails-greeter"></a>
......@@ -122,10 +122,6 @@ Then, launch an editor for the needed cleanup of the result.
included website
### Merge master
Merge the `master` branch into the one used to build the release.
### version number
If preparing a RC, skip this part.
[[!toc levels=1]]
Some [[test results]] that might be useful to keep are saved.
# Changes
Keeping an eye on the changes between released versions is one of the
......@@ -387,6 +389,9 @@ Tests to run:
# Incremental updates
The following should be tested once incremental updates are ready for
real-world deployment.
Try every update path supported by the generated update-description
......@@ -470,10 +475,12 @@ language.
* The chosen keyboard layout must be applied.
* The virtual keyboard must work and be auto-configured to
use the same keyboard layout as the X session.
* The iceweasel search engine must be localized (for languages we
ship a localized searchplugin for).
* The iceweasel spelling dictionary must be localized (for languages
that are supported by our branding extension).
* Once [[todo/fix_localized_iceweasel_search_engine]] is fixed, the
iceweasel search engine must be localized (for languages we ship
a localized searchplugin for).
* Once [[todo/select_localized_spelling_dictionary_in_Iceweasel]] is
fixed, the iceweasel spelling dictionary must be localized (for
languages that are supported by our branding extension).
# Misc
qemu -enable-kvm -boot c -m 4096 -cdrom tails.iso
Note that you need the qemu command, which is provided on wheezy by the `qemu-system` package.
* Start the VM
- with default CPU (pae)
qemu -enable-kvm -cdrom tails.iso -m 5120 -no-reboot -no-shutdown
- with 486 CPU
qemu -enable-kvm -cpu 486 -cdrom tails.iso -m 5120 -no-reboot -no-shutdown
* Open the qemu console (CTRL-ALT-2).
* Save physical memory to the `tails.dump` file (replace `0xF0000000`
(= 4GiB) with the amount of memory bytes assigned to the VM):
* Save physical memory to the `tails.dump` file (length is an integer, max size for one dump is 4G = 0xF0000000):
pmemsave <start address> <length> <filename>
e.g for 5G one has to do two dumps:
pmemsave 0 0xF0000000 tails.dump
pmemsave 0 0xF0000000 tails14.dump
pmemsave 0x100000000 0x40000000 tails5.dump
Memory erasure
Tested with [[erase_memory_on_shutdown/qemu_pmemsave]]
### PAE
without wipe : 215334680 + 62601448 = 277936128 pat = 4446978048 / 5368709120 o (82.83%)
after wipe : 0 + 0 = 0%
### 486
without wipe : 176224619 pat = 2819593904 / 3221225472 o available (87.53 %)
after wipe : 930023 pat = 14880368 / 3221225472 o available (0.005 %)
### PAE
0 patterns found after wipe
### PAE
without wipe : 215473140 + 64983491 pat = 4487306096/5368709120 o (83.58%)
after wipe : 0 (0%)
In 0.19~rc1, there's a regression: passwordless sudo is granted to the
`amnesia` user when no admin password was set.
This is due to `LIVE_NOCONFIGS`, we set in
`config/chroot_local-includes/etc/live/config.d/noroot.conf`, being
apparently ignored.
We're working this around (`bugfix/no_passwordless_sudo`) in ugly ways
for 0.19 final.
However, this should really be fixed [[!taglink todo/upstream]]:
[[!debbug 712232]].
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]]
The Unsafe Browser won't start at all in Tails 0.19~rc1. When the
`unsafe-browser` script tries to start iceweasel, it dies with:
** ERROR **: Cannot find a safe socket path in '/tmp'
and `dmesg` says:
[ 57.419802] aufs au_cpup_single:764:iceweasel[4743]: I/O Error, failed removing broken entry(-1, -1)
[ 57.419837] aufs au_cpup_single:675:iceweasel[4743]: I/O Error, i84679 exists on a upper branch but not pseudo-linked
[ ... last line repeated ~1000 times ...]
It seems 0.19~rc1's new Linux kernel (3.9) introduced an
[aufs regression](
([another thread]([email protected]/msg04187.html)).
Until there's an [[!taglink todo/upstream]] fix, a quick workaround is
to unset the sticky bit on the `$COW` tmpfs dir used for the aufs
union. This is done in the branch
[[!tag todo/qa]]
The [Memento: Learning Secrets from Process
paper, by Suman Jana and Vitaly Shmatikov, "describe(s) a new
side-channel attack. By tracking changes in the application's memory
footprint, a concurrent process belonging to a different user can
learn its secrets".
We should read it and evaluate how Tails behaves on this front,
e.g. since [[todo/hidepid]] was introduced.
As Roger Dingledine puts it, it's "not so big an issue while tails
doesn't pretend to solve that problem; but once we start playing the
VM game, you'll want to have read that paper; (or even the process
isolation game)".
For further steps, Roger also says "if you still have that question
when you've read it (i haven't read all of it), i can put you in touch
with the author".
[[!tag todo/research]]
......@@ -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.
......@@ -17,7 +17,4 @@ handling of Bluetooth and Wi-Fi works fine.
The user doc was reviewed and improved.
# Next things to do
* [[!taglink todo/test]] on various hardware (merged in `experimental`).
* Merge!
[[!taglink pending]] for 0.19.
......@@ -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